直接答案：云服务器处于“运行中”但网站打不开时，应从用户请求经过的路径逐层检查：域名是否解析到正确地址 → 公网路由和 80/443 端口是否可达 → TLS 握手是否成功 → Nginx/Apache 是否返回 HTTP → PHP、Java、Node、数据库等上游是否完成业务请求。在哪一层首次失败，根因通常就在该层或它的前一跳。
不要一开始就刷新 DNS、重启所有服务或改防火墙。多项同时变化会破坏证据，也可能让原本只有应用故障的问题扩大成整站中断。先保存错误文本、时间、访问网络和目标 URL，再从站外与服务器内部各做一次测试。
五层故障矩阵
| 层级 | 外部测试 | 服务器侧测试 | 典型现象 |
|---|---|---|---|
| DNS | 查询 A/AAAA/CNAME | 核对预期公网 IP | 域名失败、IP可访问，或解析到旧机 |
| 网络/端口 | TCP 连接 80/443 | 查看监听、安全组、防火墙 | 超时或连接被拒绝 |
| TLS | 查看证书链与 SNI | 核对虚拟主机证书 | 证书过期、域名不匹配、握手失败 |
| Web 服务 | 请求首页并看状态码 | Nginx/Apache 配置和错误日志 | 404、403、502、503、504 |
| 应用/数据 | 请求健康检查与核心接口 | 应用、PHP-FPM、数据库、队列 | 首页可开但登录、订单或接口失败 |
“浏览器转圈”是用户现象，不是根因。应记录是 DNS 错误、connection timed out、connection refused、证书警告还是具体 HTTP 状态码。不同错误对应不同层，混为“打不开”会让排查绕远。
第一层：DNS 是否指向预期地址
从至少两个公共解析器和一个目标用户网络查询 A、AAAA、CNAME。核对返回值、TTL、是否存在多条记录，以及 IPv6 用户是否拿到不可用的 AAAA。若刚切换服务器，应同时查看新旧机日志；不要因为自己电脑已生效就立即关闭旧机。
域名解析细节可参考域名解析与 TTL 故障排查。若 IP 直接访问正常、域名失败，也要检查 Web 虚拟主机的 server_name 与证书 SNI，而不只是 DNS。
第二层：公网端口能否建立 TCP 连接
外部对 80、443 做 TCP 测试，服务器上用 ss -lntp 确认进程在正确地址监听。只监听 127.0.0.1 的服务无法直接接收公网连接；监听正常但外部超时，应核对云安全组、系统防火墙、上游高防/CDN和运营商路径。
“Ping 通”不能证明 443 可用，禁 Ping 也不代表网站一定故障。ICMP 与 TCP 是不同协议。防火墙修改前保存规则，最好先保留当前 SSH 管理会话，避免错误规则把自己锁在服务器外。
第三层：TLS 与证书链
用带域名 SNI 的 TLS 客户端查看服务端证书、有效期、签发链和握手错误。直接用 IP 测 HTTPS 可能拿到默认站点证书，不能代表域名配置。若经 CDN，需分别判断“用户到 CDN”和“CDN 到源站”两段 TLS。
常见问题包括证书过期、证书文件和私钥不匹配、只安装叶子证书未带中间链、源站只允许旧协议，或 CDN 使用严格模式而源站证书无效。证书选型可参考SSL 证书类型对比。
第四层：Web 服务是否正常响应
在服务器本机用正确 Host 头请求站点，而不是只访问 localhost 默认页。运行 nginx -t 检查语法，再看错误日志中同一时间的 connect() failed、permission denied、upstream timed out 等信息。
- 连接拒绝：常见于服务未启动或端口监听错误；
- 403：权限、访问规则、WAF 或目录索引；
- 404：请求落到错误虚拟主机、路由或文件路径；
- 502：Web 服务连不上上游或上游返回无效响应；
- 504：上游超时，不应只把超时时间无限调大。
502/504 的详细处理可结合云服务器 502 和 504 排查清单。
第五层：应用和数据库是否完成业务
首页 200 只代表一条路径。还应测试登录、搜索、表单、后台、上传、支付回调和 API。应用日志与 Web 日志要按请求时间或 Request ID 对齐；数据库连接失败、连接池耗尽、队列堆积、磁盘只读、依赖接口超时，都可能让静态首页正常而业务不可用。
如果刚发布版本，先确认配置、环境变量、依赖和数据库迁移是否一致。回滚应用前核对数据库变更能否向后兼容，避免代码回滚后读不懂新表结构。
如果域名前还有 CDN、WAF 或高防入口，应再比较边缘状态码与源站状态码。边缘返回挑战页、520/522 等供应商错误，而源站直连正常，说明问题位于边缘到源站或安全策略；源站本身已 5xx，则清 CDN 通常无效。测试源站时必须带正确 Host 和 TLS SNI，并限制源站暴露，不要把绕过 CDN 的临时地址长期公开。
一次只改一层的恢复策略
- DNS 错误：恢复上一条已验证记录，保留新旧日志观察 TTL 过渡。
- 端口错误：恢复上一版安全组/防火墙规则，不把所有端口永久开放。
- TLS 错误：切回已验证证书和配置，先做语法检查再平滑加载。
- Web 配置错误：用备份配置回滚，执行
nginx -t后 reload。 - 应用错误：摘除异常实例、回滚版本或暂停故障功能，保护写入数据。
若原服务器已不稳定并需要迁移，可按低停机迁移完整指南准备新环境。需要替换资源时，可查看美国轻量云和美国弹性云服务器的实时选项。
修复后的验收
从至少两个外部网络验证 DNS、TCP、TLS 和 HTTP；确认桌面与移动端核心流程；检查 4xx/5xx、上游耗时、应用异常和数据库连接恢复；观察一段真实流量后再关闭旧实例或临时放行规则。验收记录应包含时间、测试 URL、解析结果、证书、状态码和业务结果，而不是一句“现在能打开了”。
常见问题
服务器 IP 能打开，域名打不开是什么原因？
优先检查 DNS、虚拟主机 server_name、Host 路由和证书 SNI。IP 打开的可能只是默认站点，并不代表目标域名配置正确。
Ping 不通就说明服务器宕机吗？
不一定。ICMP 可能被禁用或限速。应继续测试目标 TCP 端口和 HTTP 响应。
重启 Nginx 能解决吗？
如果只是配置未加载或进程异常，可能暂时恢复；但错误配置会让重启失败。先 nginx -t，保留错误日志，再选择 reload 或回滚。
本地能开、外地打不开怎么查？
比较不同地区的 DNS 结果、IPv4/IPv6、路由、CDN 节点和运营商。单个办公室测试不能代表全国或海外用户。
首页返回 200 就算恢复了吗？
不算。动态站必须验收登录、数据库写入、表单、上传、回调和定时任务，静态首页无法覆盖这些链路。