发布版说明

• 已对真实域名、公网 IP、具体云厂商指代做脱敏处理。
• 原始学习笔记未改动，这一版用于公开发布。

专题：云服务器网络分层排障

这篇是把前面你已经亲手踩过的那些“明明部署好了，外网就是不通”的问题，彻底拆成一层一层来理解。

目标不是背命令，而是建立一个稳定的排障顺序：

1. 请求到底有没有到服务器
2. 到了服务器以后，卡在 DNS、Nginx、应用、Linux 防火墙，还是云安全组
3. 为什么本机通了，但公网还是不通

---

一、先建立一个最重要的脑子模型

以后你部署任何应用，只要是“域名访问网站”，本质都可以拆成这条链：

浏览器
  ->
DNS 解析
  ->
公网 IP
  ->
云厂商安全组
  ->
Linux 防火墙
  ->
Nginx 80/443
  ->
反向代理到本机端口
  ->
Docker 容器里的应用

也就是说，一个请求从用户浏览器到最终应用，中间至少会过这几层：

1. DNS 层
2. 云网络层
3. Linux 主机层
4. Nginx 网关层
5. 应用层

任何一层出问题，最后表现都可能只是四个字：

“网站打不开”

这就是为什么部署排障最怕瞎猜。

---

二、为什么“网站打不开”不能只看浏览器报错

浏览器只会告诉你一个表面现象：

• 超时
• 502
• 404
• 证书错误
• 默认欢迎页

但这些现象背后的原因，差别非常大。

比如：

2.1 超时

可能是：

• DNS 没解析对
• 云安全组没放行
• ufw 拦了
• Nginx 根本没监听对应端口

---

2.2 502

可能是：

• Nginx 能接到请求
• 但后端应用端口没活
• 或 proxy_pass 指错了

---

2.3 默认欢迎页

可能是：

• 域名已经到服务器了
• 但 Nginx 没把请求交给你的站点配置
• 默认站点把流量抢走了

---

2.4 404

可能是：

• Nginx 的 404
• 也可能是后端应用自己的 404

所以真正重要的不是“看见什么报错”，而是：

把请求卡住的层找出来。

---

三、先把前面真实踩过的几个问题，按层归类

你前面已经碰过的几个问题，非常有代表性：

3.1 status.example.com 解析不出来

这是：

DNS 层问题

对应表现：

• dig +short "status.example.com" 没返回 IP

说明请求压根还没走到服务器。

---

3.2 访问到了 Ubuntu 默认 Nginx 页面

这是：

Nginx 站点匹配问题

对应表现：

• DNS 正常
• Nginx 活着
• 但请求没落到你的反代站点

---

3.3 本机 HTTPS 正常，公网 HTTPS 超时

这是：

外层网络策略问题

对应表现：

• curl --resolve ... 443:127.0.0.1 本机能通
• 公网访问 https://域名 超时

最后你已经验证过，根因是：

云厂商安全组没有放行 443

---

3.4 应用本机端口能访问，浏览器还是打不开

这是：

Nginx 反代或公网链路问题

对应表现：

• curl http://127.0.0.1:3001 正常
• 但浏览器访问域名不正常

说明应用活着，但前面的路径没走通。

---

四、DNS 层到底负责什么

DNS 的职责非常单纯：

把域名翻译成 IP 地址

比如：

dig +short "status.example.com"

如果返回：

203.0.113.10

说明：

• 用户访问这个域名时
• 最终会尝试连到这台服务器

但注意：

DNS 只负责指路，不负责网站能不能打开。

所以：

• dig 正常
• 不代表 Nginx 正常
• 不代表应用正常
• 不代表 80/443 放通

这一步只是确认“路有没有指对”。

---

五、云安全组和 Linux 防火墙，不是一回事

这个坑你已经亲手踩过一次了，非常值钱。

很多新手会以为：

我 ufw allow 443 了，那公网就该能访问了

不对。

因为至少还有一层：

云厂商安全组

以常见云厂商为例，请求从公网进来时，先过的是云平台的网络策略。

如果安全组不放行：

• 流量根本到不了你的 Ubuntu
• ufw 有没有放行都没用

所以这两层的关系应该这么理解：

5.1 云厂商安全组

是云平台外层关卡。

它控制：

• 哪些端口允许从公网进入这台 CVM

---

5.2 ufw

是 Ubuntu 机器内部的防火墙。

它控制：

• 流量到了这台机器以后，要不要继续放进来

---

5.3 所以一个端口真正能被公网访问，通常要同时满足

1. 云安全组放行
2. Linux 防火墙放行
3. 有程序真的在监听这个端口

少任何一个都不行。

---

六、端口监听层到底在看什么

就算 DNS 正常、安全组放行、ufw 放行，如果本机根本没人监听这个端口，访问照样失败。

所以你必须会看：

sudo ss -lntp | grep -E ':80|:443|:3001|:8081|:8082'

这条命令看的是：

• 80 有没有 nginx 在监听
• 443 有没有 nginx 在监听
• 3001 有没有 uptime-kuma 对应的进程或 docker-proxy
• 8081 有没有 filebrowser
• 8082 有没有 wordpress

比如前面你看到：

• 0.0.0.0:80 被 nginx 监听
• 0.0.0.0:443 被 nginx 监听
• 127.0.0.1:3001 被 docker-proxy 监听

这就说明：

• Nginx 对外入口活着
• 应用后端也活着

---

七、本机测试和公网测试，测的根本不是同一件事

这个必须区分开，不然很容易被绕进去。

7.1 本机应用测试

比如：

curl -I "http://127.0.0.1:3001"

它测的是：

• 应用本身活不活

不测 DNS，不测公网，不测 Nginx 域名匹配。

---

7.2 本机 Nginx 站点匹配测试

比如：

curl -I -H "Host: status.example.com" "http://127.0.0.1"

它测的是：

• 不经过公网
• 直接测试 Nginx 能不能按 Host 匹配到正确站点

这一步非常适合排查：

• server_name 写错
• 默认站点抢流量
• 站点没启用

---

7.3 本机 HTTPS 测试

比如：

curl -vkI --resolve "status.example.com:443:127.0.0.1" "https://status.example.com"

它测的是：

• 本机 443 上的 HTTPS 站点是否正常
• 证书是否装载成功
• Nginx 是否能处理这个域名的 TLS 请求

---

7.4 公网测试

比如：

curl -I "http://status.example.com"
curl -I "https://status.example.com"

这才是在测：

• DNS
• 公网链路
• 云安全组
• ufw
• Nginx
• 后端应用

全部串起来之后的最终结果。

所以：

本机通，不等于公网通。

这个结论你现在已经真正踩懂了。

---

八、以后排障，建议固定成这 7 步

这个顺序非常实用，后面你部署别的应用也可以直接复用。

第 1 步：先查域名解析

dig +short "你的域名"

确认是不是指向你的服务器公网 IP。

---

第 2 步：查本机应用端口

curl -I "http://127.0.0.1:应用端口"

确认应用自己活不活。

---

第 3 步：查 Nginx 域名匹配

curl -I -H "Host: 你的域名" "http://127.0.0.1"

确认 Nginx 站点有没有正确接住请求。

---

第 4 步：查 Nginx 配置和监听

sudo nginx -t
sudo ss -lntp | grep -E ':80|:443|:应用端口'

确认：

• 配置没语法错
• Nginx 真的在监听
• 应用端口也真的在监听

---

第 5 步：查本机 HTTPS

如果涉及 HTTPS：

curl -vkI --resolve "你的域名:443:127.0.0.1" "https://你的域名"

确认本机 TLS 层正常。

---

第 6 步：查 Linux 防火墙

sudo ufw status

确认 80/443 是否放行。

---

第 7 步：查云安全组

最后去云厂商控制台看：

• 入站规则有没有放行 80
• 入站规则有没有放行 443

如果这里没开，前面本机测得再漂亮也没用。

---

九、把几个常见现象和排查方向对上号

以后可以按这个表去想。

9.1 现象：dig 没结果

优先怀疑：

• DNS 记录没配
• 解析还没生效

---

9.2 现象：域名能解析，但看到默认 Nginx 页面

优先怀疑：

• 默认站点还在
• server_name 写错
• 站点配置没启用
• nginx reload 没做

---

9.3 现象：本机应用通，域名访问 502

优先怀疑：

• proxy_pass 写错
• 后端服务重启后端口变了
• 反代头部或路径有问题

---

9.4 现象：本机 HTTPS 通，公网 HTTPS 超时

优先怀疑：

• 云厂商安全组没开 443
• ufw 没放行 443

---

9.5 现象：证书申请失败，challenge 返回 HTML

优先怀疑：

• challenge 路径被 location / 吞了
• webroot 目录不对
• 默认站点接管了 challenge 请求

---

十、以后再部署新应用，你该怎么套这套方法

假设你以后继续部署：

• Gitea
• Vaultwarden
• MinIO
• Nextcloud

你其实不需要重新学一套新排障方法。

因为无非还是：

1. 这个应用本机监听哪个端口
2. Nginx 把哪个域名转给它
3. 80/443 有没有放通
4. DNS 有没有指对

所以真正值钱的不是某个项目配置，而是：

你已经有了一套通用排障骨架。

---

十一、这一课学完后，你应该真正记住的结论

1. “网站打不开”不是一个问题，而是一串链路里某一层出了问题
2. DNS 只负责把域名指到服务器，不负责网站本身能不能打开
3. 云安全组和 ufw 是两层不同的防护，缺一不可
4. 端口真正可用，必须同时满足：外层放行、内层放行、进程监听
5. 本机测试和公网测试测的不是同一件事
6. 排障要按层来，不要一上来就乱改配置

---

十二、下一步最适合继续学什么

下一课最顺的方向有两个：

方向 A：继续基础设施

写一篇：

08-专题：Nginx 站点配置实战模板

把你现在已经搭过的：

• Uptime Kuma
• FileBrowser
• WordPress

三类站点配置，抽成“我以后能复用的模板”。

---

方向 B：继续应用实战

直接上一个新项目，比如：

• Vaultwarden
• Gitea
• MinIO

这样你就能在同一套排障方法上继续练新应用。

如果按学习节奏来说，我更推荐先补模板课，再上新应用，会更稳。