阿里云服务器配置从入门到实战：安全组、SSH与HTTPS部署全解析

前阵子一个朋友买了台阿里云服务器，凌晨一点发消息说网站打不开。我远程上去一看，Nginx 监听正常，80 端口也通了，但浏览器就是一直转圈。折腾了十几分钟才发现，安全组入方向只放行了 22，HTTP 流量全被挡在外面。这个场景我见过太多次了：阿里云配置服务器这件事，最大的难点从来不是 Linux 命令，而是理不清阿里云平台的各种概念和服务器内部配置之间的关系。

这篇文章我打算按我自己配置 ECS 的真实操作顺序来写，从下单前怎么选配置，到第一次 SSH 登录、基础环境初始化、对外提供服务，再到日常故障排查。不是把官方文档复述一遍，而是把那些文档里不会写、但新手几乎都会踩的坑讲清楚。如果你刚买完服务器不知道从哪里下手，或者已经在上边折腾过一阵但总被安全组、环境变量、systemd 这些东西卡住，这篇文章应该能帮你省不少时间。

1. 买服务器前先回答三个问题：配置、地域、镜像怎么选

1.1 先想清楚用途，再谈配置

买服务器之前别急着点下单。先问自己一个问题：这台机器到底是要长期跑一个正经业务，还是只是拿来练手？这个问题直接决定你要不要多花钱。

如果是搭个人博客、放一个前后端分离的 Demo、跑一些定时脚本，1核2G 的入门实例也不是不能用。我自己早年用 1核1G 的机器跑 WordPress，白天还能撑住，一到晚上被爬虫多抓几次，MySQL 直接卡死，最后实在受不了换了 2核4G。所以我的经验是：但凡有一点预算，2核4G 是个人项目的长期省心线。这个配置跑 Nginx、一个 Java 进程或 Node 服务、MySQL、Redis，基本能在低流量下稳定运行。真要上了生产环境还带一点并发，直接看 4核8G 起步。内存比 CPU 更重要，因为大多数应用瓶颈在内存，而不是计算。

下面是常见场景和我的参考配置：

这里还想提醒一句：云服务器不像物理机，性能可以随时升级。所以买低配先用着完全没问题，但要注意选支持变配的实例规格，避免选到某些促销机型，后续升级受限。

1.2 地域、镜像、带宽：三个容易被忽略的变量

地域选择上，最需要看的是你的用户在哪里。面向国内用户，选华东、华北这些国内节点就好；如果你的用户主要在海外，那就选新加坡、美西等海外节点。跨地域访问的延迟很直观，国内用户访问海外节点，来回一趟多几十毫秒，体验会很差。很多新手看到便宜就买了海外实例，结果网站打开慢到怀疑人生。

关于可用区，同一地域下的多个可用区之间内网互通，可以搭主备，但不同地域内网默认是不通的，这点在设计多机器架构时要注意。

公网带宽这里有个常见的理解误区。按固定带宽计费，就是交固定月费，不管用没用都收那么多；按使用流量计费，是带宽峰值设一个上限（比如 5M），按实际流量结算。个人项目我一般建议按流量，原因很简单：大部分时间的实际流量很小，按流量比固定带宽省钱，而且峰值设 5M 起步完全够日常用。要是跑视频、大文件下载，才需要考虑固定带宽和更高的峰值。

镜像选择建议优先看系统的维护状态。目前阿里云官方对 Alibaba Cloud Linux 有专门优化，而且兼容 CentOS 的操作习惯；如果你比较熟悉 Ubuntu，直接选 Ubuntu 22.04 LTS 也不会错，资料多、软件源新。Windows Server 不是不能用，但会消耗更多内存，常规 Web 服务没必要。如果你拿不准，选 Alibaba Cloud Linux 3 不怎么踩坑。

2. 从下单到 SSH 连接：新手最容易卡住的几个环节

2.1 实例创建时的安全设置不是小事

下单时有一项"设置登录方式"，很多人随手选了个密码就过去了，这里值得多花两分钟想一下。

如果选密码登录，root 密码一定要设得足够复杂，尤其是公网 IP 很容易被扫描工具盯上。恶意脚本每天都在跑全互联网的 IP 段，弱密码往往撑不过一天。另一个选择是密钥对：服务器上只保存公钥，登录时用你本地的私钥做认证，私钥不会经过网络传输，安全性比密码高一个等级，而且之后写自动化脚本也更方便。私钥下载后一定放好，丢了就只能重建实例或重新绑定密钥。

如果你已经选了密码登录，之后也可以在控制台重置实例密码。但重置后要重启实例才生效，这是个容易忽略的细节。

2.2 三种远程登录方式，总有一种能用上

拿到公网 IP 后，最常见的登录方式有三种。

第一种是阿里云控制台自带的 Workbench，网页里直接打开一个终端，适合临时登录或本地没有 SSH 客户端的情况。但它受浏览器影响较大，长命令、粘贴多行内容时体验一般，我一般只在救急时用。

第二种是本地 SSH 客户端。Windows 上我用得比较多的是 Xshell 和 MobaXterm，都能保存会话、支持密钥登录、多标签窗口，比 CMD 自带的 ssh 方便不少。macOS 和 Linux 用户直接在终端里执行：

bash复制ssh root@你的公网IP

这种最干净，也最接近服务器实际使用环境。

第三种其实不算登录方式，而是登录后的基础操作：如果你用的是 Windows Server 镜像，可以通过远程桌面连接，RDP 默认端口 3389。不过这不在今天主要讨论范围。

2.3 连不上的真正原因只有一个

“SSH连接超时”大概是我被问过最多的问题。排查链路其实很固定：

1. 确认实例处于运行中，公网 IP 有没有填错；
2. 确认安全组入方向已经放行 22 端口；
3. 确认服务器内部防火墙没有拦截 22 端口；
4. 如果以上都没问题，在你本机执行 telnet IP 22 或 nc -vz IP 22，看端口通不通。

很多人喜欢一上来就怀疑是不是 SSH 配置错了，但实际上 90% 的情况出在安全组规则。阿里云的安全组相当于一台虚拟机外面的第一道防火墙，哪怕你系统里防火墙全关了，安全组没放行也一样连不进来。用 Workbench 能连上、本地终端连不上，基本就是安全组问题或者本地网络问题。Workbench 是走后端通道的，不走公网，所以不能证明公网访问正常。

另外，首次登录成功后不要急着关终端。我见过有人改完 SSH 端口，顺手把服务重启了一下，结果新端口在安全组里没放行，连接直接断开，最后只能去控制台用 Workbench 改回来。

2.4 登录后的第一步初始化：别用 root 裸奔

新服务器登录后，我建议第一件事不是装软件，而是建一个日常用的普通用户。

bash复制adduser deploy
usermod -aG sudo deploy
su - deploy
mkdir -p ~/.ssh
# 把你本地的公钥内容写入 ~/.ssh/authorized_keys

之后大部分操作都用 deploy 这个用户执行，只有需要装系统级软件时才加 sudo。这样即使某个应用被入侵，也不会直接拿到 root 权限。

如果你用的是 Ubuntu，编辑 /etc/ssh/sshd_config，把 PermitRootLogin 改成 no，再重启 sshd。注意先确认新用户能正常登录再改，别先断了自己的后路。

系统时间也建议顺手设置一下，很多证书校验和日志排错都依赖准确时间：

bash复制sudo timedatectl set-timezone Asia/Shanghai
sudo timedatectl set-ntp true

阿里云 ECS 内部访问阿里云 NTP 服务非常稳，不用再额外配置外部时间源。

3. 基础环境初始化：阿里云镜像源与常用软件配置

3.1 用阿里云镜像源，是 ECS 的原生优势

服务器上第一步经常会卡在更新软件包这一步：默认软件源在国外，拉取速度惨不忍睹。而阿里云 ECS 访问阿里云镜像站（mirrors.aliyun.com）走的是内网或高质量网络，速度会快很多。

Ubuntu 22.04 为例，先备份原始源文件：

bash复制sudo cp /etc/apt/sources.list /etc/apt/sources.list.bak

然后把 archive.ubuntu.com 和 security.ubuntu.com 替换成 mirrors.aliyun.com。一种比较稳妥的做法是用 sed 完成替换：

bash复制sudo sed -i 's/archive.ubuntu.com/mirrors.aliyun.com/g' /etc/apt/sources.list
sudo sed -i 's/security.ubuntu.com/mirrors.aliyun.com/g' /etc/apt/sources.list
sudo apt update

如果你的系统是 Alibaba Cloud Linux，默认就带了阿里云源，这一步可以跳过。CentOS 流这类的操作方法类似，关键是别把源地址写错，改完先 yum makecache 验证一下。

这里有个额外提醒：镜像源不要贪多。很多人图省事会去复制网上现成的源列表，但有些第三方源只适用于特定版本，硬套上去会导致依赖版本冲突。我只推荐使用官方源或发行版对应的阿里云镜像源。

3.2 按需安装：Git、Node.js、Java、MySQL、Redis

装软件的原则是"用到了再装"，不要一上来全装一遍。

Git 基本没什么好犹豫的，直接：

bash复制sudo apt update && sudo apt install -y git
git config --global user.name "你的名字"
git config --global user.email "你的邮箱"

Node.js 那要看你的需求。如果只是跑一些现成项目，直接用 apt 安装系统自带版本就够用：

bash复制sudo apt install -y nodejs npm

如果想用较新的大版本，推荐用 nvm 安装，这样可以在不同项目之间切换 Node 版本，改环境变量也不会污染系统。

Java 是另一个高频需求。安装 OpenJDK：

bash复制sudo apt install -y openjdk-17-jdk

装完之后系统可能不会自动设置 JAVA_HOME。这时候需要先确认 Java 的实际安装路径，一般是 /usr/lib/jvm/java-17-openjdk-amd64，然后在 /etc/profile.d/java.sh 里配置：

bash复制export JAVA_HOME=/usr/lib/jvm/java-17-openjdk-amd64
export PATH=$JAVA_HOME/bin:$PATH

保存后执行 source /etc/profile.d/java.sh，再 echo $JAVA_HOME 验证。

MySQL 的安装相对重一些。通过 apt 安装 mysql-server 后，运行 sudo mysql_secure_installation 做安全初始化，把匿名用户、默认测试库都清理掉。Ubuntu 新版 MySQL 默认 root 用户用 auth_socket 插件认证，命令行里 sudo mysql 才能进，不输入密码；如果想让 root 通过密码连接，需要额外调整认证插件。这一块网上资料很乱，我的建议是：如果不需要远程连数据库，就保持默认，所有本地应用都用 Unix socket 连接；如果确实需要远程访问，单独建一个专用用户，只授权需要的库，不要直接开放 root。

Redis 也一样，默认只监听 127.0.0.1，不要改成 0.0.0.0。如果业务需要远程访问，至少得设密码，并且在安全组里限制来源 IP，而不是对全网开放。

3.3 Maven 配置阿里云仓库，这条单独拿出来说

热搜里有“maven配置阿里云仓库”，说明这个坑踩的人特别多。默认 Maven 中央仓库在海外，每次下载依赖都像挤牙膏。解决办法是在 ~/.m2/settings.xml 里加一个镜像：

xml复制<mirrors>
  <mirror>
    <id>aliyunmaven</id>
    <mirrorOf>central</mirrorOf>
    <name>aliyun public repository</name>
    <url>https://maven.aliyun.com/repository/public</url>
  </mirror>
</mirrors>

这样 Maven 对中央仓库的依赖请求都会转到阿里云公共仓库。如果你用的是 IDEA，还需要在 Build Tools > Maven 里指向同一个 settings.xml，否则 IDEA 内置的 Maven 还是会走默认仓库。配置完以后，新项目的首次依赖下载速度差别非常大，值得提前配好。

3.4 用 systemd 托管应用，而不是 nohup

很多人启动 Java/Node 服务还在用 nohup java -jar xxx.jar > app.log 2>&1 & 这种方式。不是不能用，但进程不好管理，服务器重启之后还得手动拉起，服务崩了也无人自动重启。更稳妥的方式是交给 systemd。

比如一个 Node 应用，在 /etc/systemd/system/myapp.service 里写：

ini复制[Unit]
Description=My Node App
After=network.target

[Service]
User=deploy
WorkingDirectory=/opt/myapp
ExecStart=/usr/bin/node app.js
Restart=always
RestartSec=3
Environment=NODE_ENV=production

[Install]
WantedBy=multi-user.target

然后：

bash复制sudo systemctl daemon-reload
sudo systemctl enable --now myapp

之后看日志用 journalctl -u myapp -f，重启服务用 systemctl restart myapp，服务崩溃后 systemd 会在 3 秒后自动尝试拉起。环境变量也可以直接写在 service 文件里，有些部署脚本把密钥写死在代码里，这个问题不该在服务器配置这一层出现。

4. 对外开放服务：安全组、域名解析、DDNS 与 HTTPS 证书

4.1 安全组是流量的第一道关卡，别和系统防火墙搞混

我在开头提到的朋友就是栽在安全组上。默认情况下，阿里云 ECS 创建后只在安全组里放行 22 端口，其他端口一概不通。你在服务器上把 Nginx、MySQL、Redis 都装好了，外网照样访问不了，原因多半就在这里。

要放行 HTTP/HTTPS，去 ECS 控制台找到“安全组” → “配置规则” → “入方向”，手动添加规则。常用的规则如下：

端口和来源越少越好。很多安全事件都是因为把数据库或 Redis 暴露到公网，结果被批量扫描撞库。安全组在操作系统之外，和 firewalld、ufw 是两套体系。你既要在安全组里放行，也要保证系统防火墙没有拦截；反过来，你也不能因为系统防火墙关了就觉得万事大吉，安全组依然会把流量挡在外面。

4.2 域名解析和 DDNS：固定 IP 和动态 IP 的两种玩法

如果你的公网 IP 是固定的，域名解析很简单：在云解析 DNS 控制台添加一条 A 记录，主机记录填 www 或 @，记录值填服务器公网 IP 即可。TTL 可以设成默认，等解析生效后 ping 或 nslookup 验证一下。

但如果你的公网 IP 是动态的，问题就来了。阿里云云解析 DNS 提供了 OpenAPI，可以通过脚本定时把域名解析到最新的 IP，也就是 DDNS 的思路。

我的做法是在服务器上用阿里云 CLI：

bash复制# 获取当前公网 IP
IP=$(curl -s https://api.ipify.org)
# 更新域名记录
aliyun alidns UpdateDomainRecord \
  --RecordId <你的记录ID> \
  --RR home \
  --Type A \
  --Value "$IP"

用 aliyun alidns DescribeDomainRecords --DomainName example.com 可以查到记录 ID。然后把这段逻辑写成一个脚本，放到 crontab 里每五分钟执行一次：

bash复制*/5 * * * * /usr/local/bin/ddns_update.sh

AccessKey 建议在 RAM 里单独创建一个子用户，只授权 DNS 管理权限，不要用主账号 AccessKey 跑脚本。脚本里也不要把 AccessKey 明文提交到代码仓库，用配置文件或者环境变量读取。

4.3 免费 SSL 证书申请与自动续期：别等过期才想起

HTTPS 现在是标配，免费证书也够用。申请路径在阿里云控制台搜“SSL 证书”，选择免费证书，填写域名和申请信息。签发后下载 Nginx 格式，传到服务器上，然后修改 Nginx 配置：

nginx复制server {
    listen 443 ssl;
    server_name example.com www.example.com;

    ssl_certificate     /etc/nginx/ssl/example.com.pem;
    ssl_certificate_key /etc/nginx/ssl/example.com.key;

    # 其他配置...
}

改完一定先执行 nginx -t，通过后再 systemctl reload nginx。很多人换了证书后浏览器提示打不开或“页面不存在”，大多数是证书文件路径不对、证书链不完整，或者 Nginx 没重新加载。注意免费证书有效期比较短，到期前一定提前换，可以在控制台开启证书到期提醒，或者用 acme.sh 这类工具实现自动申请和续期。

如果只是跑 HTTP 服务，也可以加一条跳转规则，把 80 端口的请求 301 到 HTTPS：

nginx复制server {
    listen 80;
    server_name example.com www.example.com;
    return 301 https://$host$request_uri;
}

这一步做完，网站才算真正可以安心对外提供服务。

5. 日常运维三板斧：看监控、查日志、做快照

5.1 磁盘满、内存爆、CPU 飙高的快速定位

服务器用久了，最常见的三个故障我都碰到过。

磁盘满：先用 df -h 看整体使用率，再用 du -h --max-depth=1 / 逐层看哪个目录占空间。大部分情况是应用日志堆积。Nginx 日志默认放在 /var/log/nginx/，如果不做 logrotate，几个月就能膨胀到几十 GB。配置好 logrotate，或者定期压缩、清理旧日志。

内存爆：free -m 看总量和可用量。如果 swap 为 0，而内存经常吃紧，可以临时创建一个 swap 文件：

bash复制sudo fallocate -l 2G /swapfile
sudo chmod 600 /swapfile
sudo mkswap /swapfile
sudo swapon /swapfile

想要重启后仍生效，写入 /etc/fstab。不过 swap 是治标不治本，内存长期不够还是要升配，或者检查是不是应用存在内存泄漏。

CPU 飙高：用 top 或 htop 看进程，确认是哪个程序在消耗 CPU。如果是一个 Java 进程，可能要 dump 线程栈；如果是 Nginx，可能是被攻击或并发量超过预期；如果是 MySQL，重点看慢查询日志。定位到具体进程后，不要盲目 kill，先看它是不是业务必需进程，再考虑重启或优化。

5.2 阿里云监控是肉眼可见的救命稻草

在系统本身出问题之前，阿里云控制台的一些监控指标其实已经能说明问题。ECS 实例详情页可以看到 CPU、内存、网络流入流出、磁盘读写等曲线。这些指标都是平台侧采集的，即使系统已经失去响应，也能在控制台看到趋势。

建议给关键实例配置自定义报警规则。例如 CPU 使用率超过 80% 持续 10 分钟、磁盘使用率超过 85%、公网流量异常突增，都可以设置报警。报警渠道支持短信、邮件、钉钉等。这样不用天天盯着控制台，有问题时能第一时间知道。

另外，云监控配合“云助手”可以在线执行命令，比如一键清理临时文件，或者在服务器失联时收集诊断信息，这个对远程维护很有用。

5.3 定时备份与快照：给服务器上个保险

说到备份，我最想强调的一点是：不要以为数据在云上就不会丢。误操作删数据库、磁盘硬件故障、被脚本删文件，这些事每天都在发生。

阿里云控制台支持手动创建快照，在做重大变更前，比如升级系统、改内核参数、迁移环境，先手动打一个快照，出问题可以一键回滚。手动快照没有统一保留时间，要记得用完删除，避免一直扣存储费用。

自动快照策略我建议至少每三天跑一次，保留最近 7 份。如果数据重要，可以把备份文件同步到 OSS，设置生命周期规则，进一步防止误删。

数据库备份不能只依赖磁盘快照，因为快照回滚的是整块磁盘状态，不细粒度。MySQL 可以写一个简单的定时任务，每天凌晨用 mysqldump 导出所有数据库，保留最近 7 天的备份文件：

bash复制#!/bin/bash
BK_DIR="/backup/mysql"
mkdir -p "$BK_DIR"
mysqldump -u root --all-databases > "$BK_DIR/db_$(date +\%F).sql"
find "$BK_DIR" -type f -mtime +7 -delete

然后加入 crontab：

bash复制0 2 * * * /root/mysql_backup.sh

这样做过之后，即使某天数据库被搞坏了，也能恢复到最近一天的状态，不会一夜回到解放前。

最后再分享一个我自己的习惯

除了这些技术操作，我还想提一个看起来不是技术、但实际很管用的习惯：把服务器上的变更记下来。我一般会在 /srv 或 /opt 下放一个 CHANGELOG 文件，每次改了 Nginx 配置、加了定时任务、换了证书，都随手记一行。时间一长你会感谢这个习惯，排查问题的时候不用靠回忆，直接翻记录就行。另外一个习惯是把常用命令写成简短的 shell 脚本或 alias，比如快速查看磁盘、一键清空日志、手动备份数据库，这些脚本积少成多，每次用都能省下不少时间。服务器配置这件事没有什么高深魔法，就是把每个环节搞明白，再把这些环节固定成自己的操作流程。