民科心中的物理有一次我帮朋友排一台新买的阿里云服务器 ECS，他在控制台折腾了一下午，问了我一句特别经典的话：“SSH 都连上了，为什么 Nacos 就是连不上 MySQL？”其实这不是他一个人的问题。云服务器真正难的不是开机，而是从一台“能连上的机器”变成一台“能稳定跑业务的机器”。中间隔着选型、初始化、安全组、容器网络、账号权限这些琐碎但致命的细节。
这篇我打算把一台云服务器 ECS 从选型、下单、初始化、部署项目，到远程桌面故障排查、迁移到本地虚拟机的完整链路，从头到尾以实际经验的方式写一遍。适合刚接触云服务器、准备部署自己项目的同学，也适合已经被各种网络和配置问题卡住、想系统地捋一遍思路的老手。内容不背书，命令和操作都是在真实环境里趟过坑之后总结出来的。你会踩的坑，我提前给你标出来。
1. 先决定地域、规格和带宽，再去谈搭建
很多人买 ECS 的时候，第一步就输在了“随便选”。看到推荐套餐就直接下单，结果机器到手才发现用户访问慢、内存不够用、带宽小到离谱。与其买完再折腾，不如在下单前先把三个基础决策想清楚。
1.1 地域：离用户近，比离“名气大”的机房更重要
地域的选择会直接影响网络延迟、内网互通以及和周边云产品的配合方式。如果你的业务用户集中在某个区域，那就优先选择离用户更近的地域。以云产品常见的节点打比方，用户偏北方的可以优先看华北节点，偏南方的优先看华南节点，如果用户覆盖全国又没有明显的集中区域，华东这类大体量节点通常覆盖能力更均衡。我只是划个大致方向，具体你怎么选要看实际业务。
地域还有个容易被忽略的问题：同一地域内的不同可用区之间内网可以互通，但跨地域的经典网络或专有网络默认是不能直接互通的。如果你后面还要用负载均衡、数据库云服务或者对象存储，最好让 ECS 和这些产品落在同一个地域，否则内网地址访问天然就不通，只能走公网，延迟和费用都会受影响。
小项目不用纠结可用区，一般和主资源在一个可用区就行。但如果你是做双机高可用，要把两台 ECS 放在同一个地域的不同可用区，理论上可用区级别的故障不至于让整个业务一起挂。地域选错要迁移很麻烦，虽然可以通过镜像复制到其他地域，但业务数据和网络配置都要重新适配，别给自己找这个事。
1.2 规格：2核4G不是万金油，但大多数入门场景确实够用
阿里云控制台上可选实例规格非常多，共享型、通用型、计算型、内存型，甚至还有突发性能型。新手最容易踩的坑，是冲着便宜无脑选一款“突发性能实例”，以为都叫 2 核 4G 跑起来就一样，结果业务一上量 CPU 就被限制，机器卡得像老牛拉车。
所谓突发性能实例，本质是给你一个 CPU 积分池，短时间可以冲高，但长时间占用超过基准线，积分耗尽后 CPU 性能就会被打回原形。这种规格适合做开发测试、小型网站、轻量任务，比如偶尔编译一下、跑个脚本。如果你要常年跑 MySQL、Nacos、Redis、Java 应用这类常驻进程，我不建议选这类规格，老老实实选通用型或者计算型，别贪那几十块钱的便宜。
配置大小怎么判断？如果你是个人博客、静态网站、轻量接口服务，2 核 2G 或 2 核 4G 就够了。如果你想在一台 ECS 上部署“微服务全家桶”，比如 Nacos、MySQL、Redis、几个 Spring Boot 服务，那 2 核 4G 是起步，内存会是最大的瓶颈，因为 JVM 本身就吃内存，Nacos 单机版启动加运行怎么也得吃掉 1G 以上，MySQL、Redis 再来掺一脚，4G 内存就显得很局促。我实际测试下来，一台 2 核 4G 的机器跑精简版微服务倒能跑，但高峰期 OOM 风险不小；条件允许直接上 4 核 8G，你会少很多半夜被告警吵醒的经历。
1.3 带宽：固定计费和按量计费，选错会直接影响月底账单
带宽是 ECS 新手最没概念的一项。公网带宽有两种主流计费姿势：按固定带宽，付固定月费，不管你用不用流量；按使用流量，先设定带宽峰值上限，然后根据出网流量结算。按固定带宽适合流量稳定、需要保障速度的场景；按使用流量适合日常流量不大但偶尔有突发下载的场景，代价是需要盯防恶意流量和攻击流量，一旦被刷，按量账单会非常刺激。
如果你是个人项目或内部系统，我推荐直接选按固定带宽，3Mbps 到 5Mbps 通常够用。别小看这个数字，很多人买了 1Mbps 带宽，后续用 scp 传个文件慢到想砸电脑，在控制台升级带宽又是一顿操作。按流量计费也不是完全不能选，适合那种“访问量很低但偶尔要一次性传大文件”的接口服务。我自己的习惯是：平稳业务用固定带宽保底，临时场景开按量流量。
还有一件事很多人不清楚：ECS 通常只有出网流量计费，入网流量一般不计费。也就是说你从服务器下载文件会产生公网流量费用，别人上传到你的服务器一般不直接收流量费。正因为这样，做数据备份、镜像导出、大批量文件转存的时候，能走对象存储内网就走内网，千万别用公网硬扛，否则账单会教你做人。
需要模型API调用？ 免费领10W Token，多模型网关一键接入 Claude、DeepSeek 等主流模型。
2. 创建流程中那些不起眼却决定生死的选项
打开 ECS 购买页面，一堆选项往下滚，很多人只盯着价格。实际上真正影响你后续使用体验的，是登录凭证、安全组、磁盘这几个不太起眼的模块。这里我按踩坑概率从高到低逐个讲。
2.1 登录凭证：密码、密钥对到底怎么选
如果你创建的是 Linux 实例，我优先推荐密钥对登录。密钥对的原理相当于一把私钥，只有持有私钥的人能登录，比密码更抗暴力破解。阿里云控制台可以生成密钥对，下载私钥文件的时候必须第一时间保存好，因为私钥只允许下载一次，丢了基本找不回来。
但密钥对也有坑。很多新手下载了私钥，结果用本地终端连的时候不知道私钥文件要放到哪，也不知道权限不能太开放，尤其是 Windows 上的 OpenSSH 对私钥文件权限要求很严格，权限不对会直接拒绝使用。这个细节经常把第一次用密钥的人卡得生无可恋，其实把私钥文件权限改成只读或者复制到 .ssh 目录下就正常了。
密码登录也有它的使用场景。如果你是临时开一台机器做测试，或者团队里都是不熟悉命令行的同事，那密码登录更直接。但密码不能太弱，至少八位，大小写字母、数字、特殊符号都来一点。云服务器放在公网上，被扫描和爆破是家常便饭，弱密码就是在给全网扫段脚本送人头。还有一点，Linux 实例创建时如果选的是“密钥对登录”，实例初始是没有密码的，你后面想用密码登录，必须去控制台“重置实例密码”，重置之后还要重启实例才能生效，这个流程很容易让人误以为机器坏了。
2.2 安全组才是真正的“防火墙”
ECS 上最容易让新手崩溃的概念就是安全组。外人看服务器，以为防火墙是装好系统之后自己去设置的，实际上阿里云在虚拟机外面就套了一层叫“安全组”的过滤规则。实例上的端口即使已经正常监听，安全组不放行，公网照样访问不了。很多人的第一反应是检查服务有没有启动、端口有没有被占用，折腾半天，最后发现安全组规则里压根没有放行这个端口。
新购实例时系统通常会创建一个默认安全组，并按实例类型放行基本端口。比如 Linux 实例默认放行 22 端口，Windows 实例默认放行 3389 端口，ICMP 通常也放行方便你 ping。除此以外的端口默认是关着的，需要你自己加规则。假如你在服务器里启动了 Nginx，监听 80 端口，浏览器却访问不到，不要怀疑 Nginx，先去安全组控制台看有没有加一条“入方向 TCP 80 允许 0.0.0.0/0”的规则。
添加安全组规则时，有两点我想多提醒。第一，管理端口如 22、3389，授权对象不要写 0.0.0.0/0，也就是不要对全世界开放，而应该填你自己当前网络的公网 IP，比如 1.2.3.4/32。第二，同一个安全组里最好不要堆满规则，规则太多自己都容易看晕，建议按业务用途拆分安全组，比如 Web 服务组、数据库组、运维组。别让数据库的 3306 端口对所有人裸奔，否则你数据库密码再复杂也架不住天天被扫。
2.3 系统盘、数据盘和快照，是一台服务器的“保险”
购买页里磁盘部分看起来简单，但很多人低估了数据盘的重要性。系统盘默认只给几十 GB，用来装系统和软件；如果数据量大的应用，比如数据库、日志、文件上传，最好单独加一块数据盘。这里有个大坑：在控制台买了数据盘并挂载到实例后，系统并不会自动帮你格式化并挂载到某个目录，你得自己登录服务器，分区、格式化、挂载，再写入开机自动挂载配置。如果你不知道这一步，买完数据盘后在服务器里 df -h 怎么看都只有系统盘，还以为是磁盘没生效。
快照这件事，我的建议是在创建实例之后尽早把自动快照策略配上。快照相当于虚拟磁盘在某个时间点的“后悔药”，操作系统配置改坏了、文件误删了、被入侵后文件被加密了，只要快照还在，就能回滚到正常状态。快照不是完全免费的，频繁创建大量快照会产生存储费用，真正常用的没必要留几百个，保留最近一两个能用的版本就够了。另外，做重大升级或改配置之前，手动打一个快照再动手，这是云上运维成本最低的保险手段。
2.4 购买时长和计费方式怎么组合
新用户很容易在“买一个月还是一年”上纠结。我的建议是，第一次买且不确定自己要不要长期用时，可以先按量付费买一台同配置的实例跑两三天，把环境、部署流程都验证完，确认这台机器就是你要的配置，再到控制台释放按量实例，转手去包年包月买长期机器。虽然操作上多了一步，但能避免“包年买完发现地域选错”这种惨案。
包年包月的单价通常比按量便宜很多，适合长期稳定运行的业务。按量付费则适合短期测试、临时扩容、需要频繁释放重建的场景。很多团队为了让成本灵活，选择按量实例常年不关，结果月底账单比包年贵出一大截，这才意识到按量付费只是“按秒计费很细”，并不是“便宜”。你要清楚自己买的是哪种，按量实例如果长期在线，费用真的不低。
3. 新机器到手后的初始化，决定你后面能少折腾多少
服务器能连上只是第一步。我见过太多人拿到新 ECS 之后直接开始装环境，装到一半发现系统源没换、用户权限乱成一团、SSH 配置也没调。养成一套标准初始化流程，后面部署项目会省心很多。
3.1 先更新系统源，再装基础工具
拿到一台全新的 Linux 实例，我首先做的是更新系统软件包。以 Ubuntu 22.04 为例：
bash复制apt update && apt upgrade -y
apt install -y curl wget git vim net-tools lsof telnet unzip
有人会问，刚创建的机器系统本来就是新的，为什么还要升级？因为公共镜像的软件包版本可能落后于源里的最新版，很多安全补丁也要通过升级才能补上。提前把 curl、wget、vim、lsof、telnet 这些排查工具装好，后面出问题时会感谢当时的自己。
如果跑一些耗时比较长的命令，比如大版本升级、编译安装、拉取大量依赖，我建议先在终端里开一个 tmux 或 screen 会话，在会话里执行。云服务器 SSH 连接偶尔会断，一旦连接断开，前台任务很容易被中断，尤其是编译任务跑到一半断了非常难受。tmux 能让你断开后重新连上也看到任务还在跑，这是运维基本操作。
3.2 别天天用 root 跑业务，创建一个日常用户
直接用 root 操作虽然方便，但风险很大。一旦命令写错，比如误删了系统目录，后果是毁灭性的；如果被入侵，攻击者拿到的是 root 权限，你连挣扎的机会都没有。我习惯是创建一个普通用户，给它 sudo 权限，日常部署都用这个用户操作。
Ubuntu 上可以这样建，sudo 用户组通常叫 sudo：
bash复制adduser ops
usermod -aG sudo ops
如果系统是 CentOS 或 Alibaba Cloud Linux，用户组一般叫 wheel，把 sudo 换成 wheel 即可。建议创建用户时设置一个强密码，然后把你的公钥放到这个用户的 authorized_keys 文件里，后续都用密钥登录这个普通用户，需要提权时才用 sudo。
这一步会被很多人跳过，觉得“就我一个人用，不用这么折腾”。但养成习惯之后，你会发现权限隔离不只是安全上的洁癖，也是让你在排查问题时思路更清晰的一种手段：哪些进程是 ops 启动的，哪些是 root 启动的，出了问题能快速分清楚。
3.3 SSH 加固：端口、root 登录、密码认证
Linux 服务器最常见的攻击入口就是 SSH。默认 22 端口加密码认证，一天能被扫几千次，虽然强密码不一定被破解，但完全没有必要把所有风险都暴露在外面。我推荐做这几个加固动作：
- 把 SSH 端口从 22 改成其他高位端口，比如 22022。
- 禁止 root 用户直接 SSH 登录。
- 如果已经配置好密钥登录，把密码登录关掉，只保留公钥认证。
修改 /etc/ssh/sshd_config：
bash复制Port 22022
PermitRootLogin no
PasswordAuthentication no
PubkeyAuthentication yes
改完先检查语法再重载：
bash复制sudo sshd -t
sudo systemctl reload sshd
这里必须提醒一句，修改 SSH 配置前，先在阿里云控制台的安全组里把新端口放行，比如 22022。然后保持当前 SSH 会话不要断开，另开一个终端测试能否用新端口连上。确认没问题再断开旧会话。否则你改完配置发现新端口安全组没放行，又关了密码登录，那就只能去控制台用 VNC 远程连接慢慢修了。
阿里云控制台的 VNC 远程连接，是你在 SSH 被锁在外面时的最后救命稻草。它模拟的是显示器、键盘鼠标，相当于直接坐在服务器前操作，不需要走 SSH。遇到任何 SSH 配置问题，都能靠它进场修复，这个入口一定要记牢。
3.4 安全组和实例内防火墙，别搞“双重保险”
有些同学看到这里会问：那我还要不要在服务器里面把 firewalld 或者 ufw 打开？我的建议是，如果你不是特别清楚两者的配合关系，日常只依赖阿里云安全组就够了。
安全组在虚拟机外部做过滤，实例内的防火墙在系统内部做过滤，两者叠加会出现一个很尴尬的问题：你查安全组发现端口放行了，但连不上；再查服务器内防火墙，发现另一个规则把端口挡了。规则越多，排查越难。我实际推荐的方式是：边界访问控制全部交给安全组，实例内部除非有特别的合规要求，否则不额外启用防火墙。这样遇到网络问题，只需要看一个地方的规则，思路清晰得多。
3.5 数据盘初始化：控制台挂载后不等于系统里能用
前面提到数据盘挂载后不会自动出现在根目录下。当你用 lsblk 看到一块未分区、未挂载的云盘时，需要自己做分区、格式化和挂载。大致流程是：
bash复制sudo fdisk /dev/vdb
sudo mkfs.ext4 /dev/vdb1
sudo mkdir /data