企业官网建设流程全解析

第一次打开国际版云控制台准备买一台云服务器的人，十有八九会在“创建实例”这一页卡住——不是不会点按钮，而是页面上每一个下拉框都在问你要钱：地域选偏了，延迟翻倍；计费方式选错了，一个月后账单让人怀疑人生；安全组端口没开，命令行里那行 ssh 敲一百遍也连不上。我前后帮人配过几十台机器，从个人博客、小工具后台到小团队的业务服务，真正难的从来不是“点创建”这个动作，而是点下去之前脑子里有没有一张清楚的图。这篇就把这张图摊开讲：从下单前的三个决策，到实例创建页每一个选项背后的含义，再到用密码或密钥把远程连接真正打通，最后补上连上之后必须马上做的收尾动作。不管你是第一次买云服务器，还是买过几次但每次都要重新查文档，都能照着往下走。

1. 下单之前先想清楚的三件事

很多人把买云服务器当成买手机——看配置、比价格、下单。但云服务器更像租房：位置、租期、面积这三项一旦定下来，后面所有事情都被它们约束着。这一节不讲怎么点按钮，只讲按钮背后的取舍逻辑，因为这三个决策错了，后面配置得再漂亮也是白费。

1.1 地域节点：延迟、内网互通与库存的三方拉扯

地域选择的第一原则非常朴素：你的用户在哪儿，机器就放在哪儿。这不是玄学，光在光纤里跑，每 1000 公里大概 5 毫秒，往返翻倍，再加上路由跳数和中间设备处理，物理距离 1000 公里往往对应 10 到 20 毫秒的实际 RTT。跨大洲的访问通常在 150 到 250 毫秒之间，这个量级对静态页面还能忍，对交互型应用就是明显的“卡一下”。

第二原则容易被忽略：同一地域内的不同可用区之间走内网，跨地域之间默认不通内网。如果你的应用服务器要连数据库、要连缓存，这两台机器必须放在同一个地域，最好放在同一地域的不同可用区，既享受低延迟内网又保留故障隔离。有人图便宜把数据库放在 A 地域、应用放在 B 地域，结果每次查询都要走公网绕一圈，延迟和流量费双输。

第三原则是库存现实：不是每个地域都有全量规格。想跑大内存服务或者带 GPU 的实例，很可能只有少数几个节点有货，创建页面上规格列表是灰的，不是你不会选，是那个区域确实没有。所以正确的顺序是：先按“离用户近”筛出两三个候选地域，再看这些地域里有没有你需要的规格族，最后比对价格。

还有一条实操建议：如果业务主要面向欧美用户，别因为“看着熟悉”就把机器放在亚洲节点，然后靠 CDN 补延迟。CDN 能救静态资源，救不了 API 请求。源站位置错了，后面所有的优化都是在给最初的那个错误决策打补丁。

1.2 计费模式：包年包月、按量付费与竞价实例的真实差别

国际站控制台下单时最常见的选择是两类：包年包月（预付费）和按量付费（后付费），部分场景还有竞价型实例。三者的差别不只是“先付还是后付”，而是资源锁定程度和风险承担方的不同。

包年包月本质上是长期租约，折扣力度最大，通常能比按量付费便宜一半以上，缺点是资源被锁死，中途退订往往有折损或者不退。适合已经确定要长期跑的业务，比如公司官网、已经上线的后台服务。按量付费按秒或按小时计量，随时可以释放，适合做测试、做临时任务、做压测；它的风险在于“忘记释放”，一台中等配置的机器挂一个月不关，账单数字会相当难看。

竞价型实例是价格随供需浮动、可能被系统回收的类型，价格能低到按量付费的一两折，代价是回收前只有很短的通知时间。它适合无状态的批处理任务，比如视频转码、数据清洗、爬取归档这类“被打断可以重跑”的活。绝对不要拿它跑数据库或者有状态的服务，我见过有人图便宜用竞价实例跑主库，凌晨被回收，第二天全组人一起对日志。

这里有个高频误区必须点出来：按量付费的实例“关机”不等于“停止计费”。多数平台区分“普通关机”和“节省停机模式”，普通关机只停 CPU 和内存的计算资源，云盘、公网 IP 依然照常收费；只有开启节省停机模式（部分规格不支持）才可能免掉计算部分的费用。所以临时不用了，最干净的做法是打快照、然后释放实例，而不是按一下关机就当没事了。

1.3 规格族：把“够用”算出来，而不是凭感觉猜

规格族的核心参数是 vCPU 和内存的比例。通用型一般是 1:2 或 1:4，计算型偏 1:1 或 1:2，内存型能到 1:8。选错的典型症状是：Web 服务选了内存型，钱花了但 CPU 先跑满；数据库选了计算型，CPU 很闲但内存不够，频繁刷盘导致响应忽快忽慢。

估算方法我一般按这个顺序走：先明确应用类型，再给一个保守起点，上线后用监控数据回调。纯静态站点、轻量反向代理，1 核 1G 到 2 核 2G 足够；跑 WordPress 这类带数据库的应用，2 核 4G 是比较稳的起点；Java 应用要额外留出堆外内存和元空间，2 核 4G 跑一个中等 Spring 服务就偏紧了，建议 2 核 8G 起步；自建数据库，内存至少给到数据热集的 1.5 倍以上，2 核 8G 是底线。

还有一个坑值得单独说：突发性能型实例（很多平台用 t 系列命名）。这类机器的基准 CPU 性能很低，靠“积分”在需要时冲高。刚买回来测试时飞快，跑了几天积分耗尽，CPU 被限制在基准线，网站突然变得奇慢无比，而监控上 CPU 使用率显示只有 20%，看着完全正常。如果你的服务是持续有负载的（比如常驻的 API 服务），别碰这类实例；如果只是每天偶尔跑一次脚本，它会非常划算。

带宽这块也要算，不能拍脑袋。固定带宽和按流量计费各有适用场景。给一个实际估算例子：假设日均 1 万 PV，页面加上图片平均 800KB，那月流量大约是 10000 × 800KB × 30 ≈ 234GB。再看峰值带宽：如果 30% 的访问集中在晚间一小时内，就是 3000 次请求 × 800KB ≈ 2.4GB，除以 3600 秒约 0.67MB/s，换算成带宽约 5.3Mbps。所以 5Mbps 的固定带宽对这个站点是够的，按流量计费则要看月总量是否超过固定带宽折算的额度。把这两个数算出来再去下单，比在页面上反复犹豫有效率得多。

2. 创建实例页面上，每个选项在决定什么

点进创建页面，从上到下大概有七八个区块。新手容易把它当成填空题一路往下点，实际上每一栏都在给这台机器定终身，其中镜像、存储、网络、安全组这四项改起来的成本最高。这一节按“改起来最麻烦”的顺序讲。

2.1 镜像：随手点过的一栏，决定后面几小时的命运

镜像就是这台机器的“出厂系统盘”，选定之后想换只能重装系统，数据全部清空。控制台上的镜像一般分四类：公共镜像（官方原版操作系统）、自定义镜像（你自己做的模板）、市场镜像（预装了应用环境，部分带额外授权费用）、社区镜像（他人共享，慎用）。

我的默认选择是公共镜像里的长期支持版本，理由很实际：干净的系统和干净的文档是对应的，出问题时能查到的资料最多。市场镜像看着省事，一键装好运行环境和面板，但代价是里面预装的组件版本、目录结构、配置文件位置全都是别人定的，后面想按官方文档操作时经常对不上，排查问题的时间成本远高于省下的那半小时安装时间。如果确实要用，务必先确认它是否额外计费、是否有授权限制。

系统版本的选择上，同样优先选长期支持版。要注意的是，很多新的稳定版本出来后，第三方软件源的适配会滞后一段时间，如果你依赖某些特定的运行环境，保守一点选上一代长期支持版反而更省事。另外，默认登录账号在不同发行版上不一样，有的允许直接用 root，有的默认用普通用户加 sudo，创建时页面上通常会写清楚，别凭印象去试。

2.2 存储：系统盘、数据盘与那个“扩容后看不见”的坑

创建页面上会让你选系统盘类型和容量，还可以额外挂数据盘。云盘类型一般分几档，从高到低大致是超高 IO 型、SSD 型、高效型，差别体现在 IOPS 和吞吐上限上，价格也依次递减。

系统盘 40G 到 50G 起步对纯系统来说是够的，但要注意日志、容器镜像、临时文件都会往系统盘里塞。我的习惯是：系统盘给到 60G 以上，业务数据单独挂一块数据盘。这样做的好处很直接——系统出问题可以放心重装，数据盘挂上去数据还在；备份和快照也能分开管理，省钱。

这里有个几乎人人都会踩一次的坑：在控制台上把云盘从 50G 扩到 100G，登录系统一看，df -h还是显示 50G。原因是控制台的扩容只改了块设备的大小，文件系统还没扩。Linux 上需要先扩分区再扩文件系统，以常见的 ext4 为例：

# 查看磁盘情况，确认设备名，例如 /dev/vdb lsblk # 扩展分区（分区号和设备名按实际情况替换） sudo growpart /dev/vdb 1 # 扩展文件系统 sudo resize2fs /dev/vdb1 # 如果是 xfs 文件系统 sudo xfs_growfs /data

顺序不能反，先扩分区再扩文件系统。另外，扩容操作本身不可逆，扩之前打个快照是基本操作。

2.3 网络：专有网络、公网 IP 与带宽计费方式

网络部分有几个概念容易混。专有网络（VPC）就是你自己的一个逻辑隔离网段，交换机（子网）是网段里的进一步划分。规划网段时有个实用建议：不要选和公司办公网相同的网段，比如公司内网用的是 192.168.0.0/16，你的 VPC 就别也用这个段，否则以后想打通内网互联时会撞车，改网段比重建还麻烦。

公网 IP 这块要区分两种：创建时直接分配的固定公网 IP，和后来单独申请的弹性公网 IP。前者跟着实例走，实例释放 IP 就没了；后者可以解绑再绑定到另一台机器，做迁移和故障切换时非常有用。带宽计费方式选固定带宽还是按使用流量，取决于流量曲线——流量平稳选固定带宽更划算，流量集中在少数几天（比如做活动）选按流量计费更省。

还有一种情况：机器根本不需要公网 IP。比如数据库、内部服务，只通过跳板机或控制台自带的远程连接功能访问，这样既省钱又减少暴露面。控制台一般提供网页版的远程连接（有的叫 VNC 或远程终端），在没配好网络之前，这是救命的入口——配置错了防火墙把自己关在外面，就靠它进去救。

2.4 安全组：远程连不上的头号元凶

安全组是实例级别的虚拟防火墙，规则分入方向和出方向，按优先级匹配。绝大多数“SSH 连不上”的问题，根子都在这里。新建安全组时的默认规则在不同平台、不同模板下差别很大，有的只放通 22 端口，有的连 22 都不放。

调试阶段图省事把 22 端口对 0.0.0.0/0 全开，是最常见的做法，但这是把机器暴露在公网上被暴力尝试。正确的节奏是：先临时放开把连接跑通，跑通之后立刻收窄到自己的固定出口 IP。查自己出口 IP 很简单，在本地终端执行一条查询命令就能拿到，然后把这个地址填进授权对象，写成x.x.x.x/32。

安全组是有状态的：你放通了入方向的某个端口，这条连接的回包会自动放行，不需要再配出方向规则。这个特性很多人不知道，白白多写一堆规则。另外，一台实例可以绑定多个安全组，规则取并集，所以排查时别忘了看看是不是绑了别的组。

3. 凭据配好，把远程连接真正打通

实例状态变成“运行中”只是机器开了机，离你能操作它还有一段距离。这一段路的三个关键点：登录凭据、连接方式、以及连不上时的排查顺序。

3.1 密码方式：设置时机与首次登录的细节

创建实例时一般有两种初始化方式：设置密码，或者绑定密钥对。选密码方式的话，创建页面上会让你输入密码，复杂度要求通常是大小写字母加数字，长度 8 位以上。如果创建时没设，也可以创建完成后在控制台重置密码，但要注意：重置密码在多数平台上需要重启实例才生效，不是点完立刻能用。有人重置完密码马上连，连不上就以为密码错了，其实是没重启。

Linux 的默认登录账号通常是 root，Windows 是 Administrator。第一次登录用这样的命令：

ssh root@<公网IP>

首次连接会提示确认主机指纹，输入 yes 继续，然后输密码。密码输入时终端不显示任何字符，这是正常的，不是键盘坏了。

关于密码方式，我的真实建议是：只在第一次登录或者临时救急时用，长期用密码登录风险太高，公网上的自动化扫描每天都在跑，弱密码撑不了多久。跑通之后尽快切换到密钥方式，并把密码登录关掉。

3.2 密钥对：生成方式与“放错位置”的代价

密钥对是一对文件：公钥放在服务器上，私钥留在你本地。登录时服务器用公钥验证你手里的私钥，验证通过就放行，全程不需要传密码，安全性高得多。

两种生成方式各有适用场景。控制台生成最省事，创建实例时直接选新建密钥对，平台会把私钥给你下载一次，务必当场保存好，关掉页面就再也拿不到了。本地生成更适合多台机器统一管理，用ssh-keygen生成后把公钥内容粘贴到控制台导入：

# 生成 ed25519 密钥对，比 RSA 更短更快，现代系统普遍支持 ssh-keygen -t ed25519 -C "work-laptop" -f ~/.ssh/cloud_key # 私钥权限必须是 600，否则 ssh 会拒绝使用 chmod 600 ~/.ssh/cloud_key # 用指定私钥连接 ssh -i ~/.ssh/cloud_key root@<公网IP>

私钥权限这一条是新手最容易卡住的地方。ssh 出于安全考虑，会检查私钥文件权限，如果是 644 或者更宽松，会直接报 “bad permissions” 并拒绝使用。Windows 上更麻烦，文件权限是从父目录继承的，光改文件属性没用，需要在属性里关闭继承再单独授权当前用户。我见过有人在这上面折腾一下午，最后发现只是权限位的问题。

如果私钥真丢了，没有补救办法，只能在控制台解绑密钥对、重新绑定一个新的，或者改回密码登录。这也是为什么建议把私钥放在固定位置并做好备份——不是备份到公开的地方，是备份到你自己的加密存储里。

3.3 连不上？按这四层顺序排查，别乱试

连接失败的时候最忌讳的是瞎改配置：改一下安全组、改一下防火墙、改一下 sshd 配置，最后不知道是哪一步起了作用，下次出问题还是不会。正确做法是按网络路径从外到内逐层验证，每一层确认通了再往下走。

第一层，实例本身。控制台上看状态是不是“运行中”，有没有因为欠费或者违规被停。这一层不通，后面都白搭。

第二层，网络可达性。用ping测公网 IP，能不能通。注意有些平台默认不放通 ICMP，ping 不通不代表网络不通，用nc -zv <IP> 22或telnet <IP> 22直接测端口更准。

第三层，安全组和系统防火墙。安全组在控制台看，规则是否放通 22 端口、授权对象是否包含你的 IP。系统内部还有一层防火墙，firewalld 或 ufw 默认可能是开着的，需要在控制台网页版远程连接里进去确认：

# 查看防火墙状态 sudo systemctl status firewalld sudo ufw status # 查看 sshd 是否在监听 22 端口 sudo ss -lntp | grep :22 sudo systemctl status sshd

第四层，本地网络环境。有些公司网络或公共网络会封掉 22 端口出站，症状是 ping 得通但端口连不上。验证方法是换个网络环境试一下，比如切到手机热点。如果确认是本地网络限制，可以把 sshd 的监听端口改成 2222 之类，同时在安全组放通对应端口，绕开限制。

ssh -v这个参数值得记住，它会把整个握手和认证过程打印出来，卡在哪一步一目了然。很多人遇到问题只会反复重输密码，加上-v之后几十秒就能定位。

3.4 Windows 实例用远程桌面连：几个必须知道的细节

Windows 实例走的是 3389 端口的远程桌面协议。安全组要放通 3389，本地用系统自带的远程桌面客户端连接，填公网 IP，用户名 Administrator，密码是创建时设置或后来重置的。

第一个细节：重置密码后需要重启实例才生效，这一点和 Linux 一样，但 Windows 上更容易被忽略，因为连接失败时的报错信息比较笼统，容易被误判成网络问题。

第二个细节：远程桌面默认限制同时连接数，多人共用一台机器时会出现“踢人”的情况。如果确实需要多人使用，得在系统里单独配置多用户会话，这属于额外工作量，能避免就避免——给每个人开独立账号更规范。

第三个细节：Windows 实例的系统盘占用增长比 Linux 快得多，更新包、临时文件、日志堆积都很快。系统盘别给太小，60G 起步比较稳，同时把自动更新和日志清理策略设好，否则几个月后磁盘满了，远程桌面登录会直接失败。

4. 连上之后，这几件事别拖到明天

机器能登录，只是完成了“能开机”这件事。真正让它稳定跑起来的，是接下来这几步收尾。我见过太多人连上就急着装环境、传代码，结果一周后磁盘满了、时间错乱了、或者账单突然翻倍，回头补这些基础工作反而更费时间。

4.1 系统更新、时区与时间同步

新创建的实例，系统包往往不是最新的。第一件事是更新一遍：

# Debian / Ubuntu 系 sudo apt update && sudo apt upgrade -y # RHEL / CentOS / 兼容系 sudo dnf update -y

更新完重启一次，让内核更新生效。然后检查时区。默认时区可能是 UTC，日志时间和你本地时间差 8 小时，排查问题时看着日志一脸懵。

timedatectl sudo timedatectl set-timezone Asia/Shanghai

时间同步也要确认。云环境里的时钟漂移虽然不严重，但一旦偏了几十秒，涉及签名校验、证书验证、分布式协调的服务就会出怪问题。主流发行版默认启用了时间同步服务，用timedatectl看 NTP synchronized 是否为 yes 就行，没有的话装 chrony 或 systemd-timesyncd 启动即可。

4.2 快照与备份：改配置之前先留退路

云盘的快照是最省事的备份方式，几秒钟就能给整个盘拍一张，出问题可以回滚。手动快照适合“我要改配置了，先拍一张”的场景，自动快照策略适合日常兜底——设置每天或每周拍一次、保留最近若干份，成本可控。

我的习惯是三条：装完基础环境拍一张，叫“初始环境”；装完应用跑通拍一张，叫“上线前”；之后每次做重大变更（升级数据库、改网络配置、动系统内核）之前再拍一张。快照按实际占用空间计费，删掉旧快照能省不少钱，但别删“初始环境”那张，它是你最后的重装替代方案。

注意：快照不等于备份到另一个地方。如果整块云盘出问题，同区域内的快照也可能受影响。关键数据还是要定期导出到独立的存储服务里，快照解决的是“误操作回滚”，不是“灾难恢复”。

4.3 告警和预算：把意外扣费关进笼子里

按量付费的机器最容易出的事就是忘记释放。开个预算告警是成本极低的保险：在费用中心设一个月度预算，超过阈值就发邮件，一旦出现异常扣费能第一时间发现。

资源告警同样要配。CPU 持续打满、磁盘使用率超过 85%、带宽跑满，这些都是服务要出问题的前兆，等用户反馈“网站打不开”时已经晚了。云监控里给这几项设阈值，通知方式选邮件加短信，几十秒就能配完。

磁盘告警尤其重要。Linux 上根分区满了会导致 sshd 无法写入日志进而拒绝登录，那时候连远程连接都进不去，只能靠控制台的网页终端救。提前配好告警，比事后救火轻松太多。

4.4 不用了就释放：停机不等于停费

这条前面提过，但值得再强调一次。按量付费的实例，普通关机状态下云盘和公网 IP 照常计费；弹性公网 IP 解绑后闲置也可能收费；快照一直留着会累积存储费用。确认不再需要时，正确的顺序是：打最终快照，解绑并释放弹性 IP，最后释放实例。释放前再确认一遍数据有没有导出，因为实例释放后本地盘数据不保留。

包年包月的机器到期前记得处理续费设置。如果确实不用了，提前了解退订规则，别等到自动续费扣完款才发现。这类事情发生后基本没得商量，规则在下单时就写在页面上了。

我自己的做法是给每台按量付费的机器在日历上设一个到期提醒，标签写清楚用途，一个月后回来看一眼——还需要的续上，不需要的直接释放。听起来很土，但确实帮我省下过好几笔莫名其妙的支出。

最后分享一个实际操作的体会：整个流程里最容易出问题的从来不是技术难点，而是那些“以为默认就是对的”选项。地域默认选第一个、镜像默认选最新版、安全组默认不动、计费方式默认按量付费——这四个默认值凑在一起，就是延迟高、兼容性差、连不上、还持续扣费的标准剧本。花十分钟把这几项主动改一遍，后面能省下几个小时。