网站流量增长后出现“有时能打开、有时超时”，容易让人先怀疑美国服务器容量不足。但无法访问并不等于资源耗尽：域名解析错误、入口端口不通、防火墙拦截、反向代理找不到上游，都可能表现为网页打不开。排查的价值在于先确定请求停在哪一层，再判断是否与高峰负载有关，避免在入口尚未打通时盲目扩容。

可先从受影响的网络访问域名，记录解析结果、连接目标、报错和发生时间；再对已确认的入口地址测试端口，并在服务器上核对监听、防火墙、代理与应用状态。所有时段、所有访问来源都失败，优先核对解析和入口；只在高峰期部分请求失败，再重点比较并发、超时、连接数与资源余量。这个顺序能把“请求没有到达服务器”和“请求到达后处理不过来”分开。

先固定故障画像：谁访问、何时失败、失败到哪一步

开始操作前，准备受影响域名、预期入口地址、服务器控制台或 SSH 权限，以及可查看的代理和应用日志。最好保留一次失败时的时间、客户端网络、浏览器错误或 HTTP 状态码，并从另一条网络复测。下文命令中的 www.example.com 和 203.0.113.10 都是示例，执行前必须替换为实际域名和已核实的入口 IP；示例 IP 不能用于访问真实服务器。

先把现象分组，比笼统记录“打不开”更有用：

同时记录负载条件：故障是否仅在峰值请求量上升时出现，静态资源和动态页面是否都失败，健康检查与真实业务请求是否一致。若低负载时也稳定复现连接失败，先不要用 CPU、内存占用解释它；若只有动态请求在高峰期超时，才有理由进一步测量应用处理能力。

DNS：先确认域名把请求送往哪里

DNS 排查的目标不是只看“有没有返回 IP”，而是核对返回的记录是否符合当前网站入口设计。域名可能直接指向服务器，也可能先指向代理或其他对外入口；不能把解析结果与源站 IP 不同直接判为错误。

在安装了 dig 和 curl 的 Linux 或 macOS 客户端上，从受影响网络执行：

DOMAIN=www.example.com

dig "$DOMAIN" A
dig "$DOMAIN" AAAA
dig "$DOMAIN" CNAME
curl -4 -sS --max-time 10 -o /dev/null \
  -w 'http=%{http_code} remote=%{remote_ip} dns=%{time_namelookup} tcp=%{time_connect} tls=%{time_appconnect} first=%{time_starttransfer} total=%{time_total}\n' \
  "https://$DOMAIN/"

dig 用来查看 IPv4、IPv6 和别名记录；curl 显示实际连接的远端地址与请求耗时。这里的各项时间是从请求开始计算的阶段时间点，不应直接相加。http=000 通常表示尚未取得 HTTP 响应，还要结合 curl 的错误信息判断是解析、连接还是 TLS 失败。示例中的 10 秒仅是本次测试的等待上限，不是网站性能标准。

可按结果作进一步区分：

• 受影响网络解析失败，其他网络正常：比较两侧解析结果和缓存，并核对权威 DNS 记录。单一客户端的失败不能直接证明服务器故障。
• A 记录可用，但存在 AAAA 记录且部分 IPv6 客户端失败：在具备 IPv6 连通性的客户端上另用 curl -6 测试。客户端自身没有 IPv6 时，测试失败不能归因于网站。
• 解析到非预期入口：先核对当前生效的记录、别名链及网站入口配置，再决定是否修改。修改前保存原记录和 TTL，确认回退方式；不要为了测试把正在使用的域名直接改指源站。
• 解析正确但请求仍失败：进入端口与入口检查。DNS 正确只说明找到了地址，不代表该地址正在提供网站服务。

如果网站经由代理，直连源站只能作为已获授权且源站允许直连时的对照测试，不能代替公开域名的访问结果。

网络入口与端口：连接究竟停在外面还是服务器上

先确定网站预期由哪个地址、哪个端口接收连接，以及入口是否另有转发。在外部 Linux 或 macOS 客户端上，可以对已核实的入口 IP 测试 TCP 端口：

ORIGIN_IP=203.0.113.10

nc -vz -w 3 "$ORIGIN_IP" 443

nc 成功只证明该 TCP 端口接受连接，不能证明证书、代理配置或页面正常。如果没有安装 nc，可继续用前面的 curl 观察连接阶段。连接超时可能是中间路径丢包、入口策略拦截或目标无响应；连接被拒绝则更应核对监听与转发。仅凭一次外部测试，不能断定是哪一道防火墙造成的。

如果该 IP 确实是允许直连的 HTTPS 源站，可保留域名及 TLS SNI 信息作对照：

DOMAIN=www.example.com
ORIGIN_IP=203.0.113.10

curl -4 -sS --max-time 10 \
  --resolve "$DOMAIN:443:$ORIGIN_IP" \
  -o /dev/null -w 'http=%{http_code} remote=%{remote_ip}\n' \
  "https://$DOMAIN/"

此命令仅对本次请求指定解析结果，不修改系统 DNS。若公开域名失败而获准直连的源站正常，应继续检查两者之间的代理、入口策略和解析路径；不能仅凭对照结果认定 DNS 一定有错。若源站按设计禁止直连，此测试失败也不能说明应用故障。排查证书问题时不要随意加 -k 跳过验证，否则会掩盖真实的 HTTPS 错误。

在美国服务器内部，若系统为 Linux，可检查实际监听：

sudo ss -lntp

找到预期端口后再判断绑定地址。代理监听在 127.0.0.1，通常不能直接接收发往服务器公网地址的连接；但应用只监听 127.0.0.1、由同机代理转发，可能完全符合设计。需要对照的是实际访问路径，而不是要求每个进程都监听公网地址。

当外部端口不通、内部监听却正常时，沿入口逐项核对：入口地址或转发是否正确、服务商侧入站规则是否放行预期来源和端口、操作系统防火墙是否拦截；若代理与应用分处不同主机，还要检查代理到上游的出站与入站规则。Linux 服务器应先确认实际使用的防火墙管理工具，再只读查看对应规则；例如使用 UFW 时可执行：

sudo ufw status verbose

这条命令只适用于已使用 UFW 的环境，不能代表服务商侧规则或其他防火墙的状态。不要为定位故障直接关闭整套防火墙。确需调整规则时，先保存现有规则与入口配置，确认控制台等备用管理通道，明确会影响的来源和端口，再做最小范围修改；验证无效或影响扩大时，按保存的配置回退。对外网站入口与仅供代理访问的应用端口，不应混为一谈。

代理与应用：端口通了，为什么页面仍不可用

TCP 连接和 HTTPS 握手成功后，请求仍可能停在反向代理，或进入应用后处理失败。先比较公开请求返回的状态与同一时段日志：

• 403：检查代理、安全策略和应用权限；它说明收到了 HTTP 响应，不等于服务器宕机。
• 502：常见于代理无法从上游取得有效响应；核对上游地址、端口、协议和应用进程。
• 504：重点比较代理等待上游的耗时与应用处理耗时，判断是上游慢还是上游链路不通。
• 503：可能是维护、限流或服务暂不可用，需以产生该状态码的组件日志为准。
• 3xx 或 200：也要确认跳转目标和实际业务页面；首页返回 200 不代表登录、提交等动态请求正常。

若环境确实使用 Linux、systemd 和 Nginx，可以只读检查代理状态与配置语法：

systemctl status nginx
sudo nginx -t
sudo journalctl -u nginx --since '15 minutes ago' --no-pager

如果代理不是 Nginx，或服务单元名称不同，应先核实实际服务名，再使用对应的状态与日志命令；不要照搬服务名。日志可能包含访问来源和请求信息，留证与分享时应注意脱敏。随后按代理配置中实际的上游地址和端口，从代理所在主机测试上游健康接口或代表性轻量请求。上游只对本机开放时，从外部网络测试它并没有诊断意义。

判断可以落在三个边界上：代理没有收到请求，回查 DNS、入口和防火墙；代理收到请求但连不上上游，回查上游监听、两端规则与进程状态；上游收到请求却处理过慢或报错，再分析应用日志、依赖调用及资源压力。修改代理转发或重启服务前，应保存原配置、确认影响范围和回滚方式；修改后先检查配置有效性，再通过公开入口验证，不要把“进程已启动”当作修复完成。

高峰才失败：用实测余量决定是否需要扩容

访问路径已经确认正确，仍只在高峰出现超时或 502、503、504，才进入容量判断。这里至少要把四类变量放在同一时间窗口：峰值请求速率、请求类型占比、响应或处理耗时、应用可承载的并发上限。动态页面、上传和静态资源消耗的资源不同，不能只用总访问量推算服务器够不够。

对相对稳定的一段采样窗口，可以用以下关系估算正在处理的请求数：

平均在途请求数 ≈ 该窗口的平均请求速率 × 同一窗口的平均请求耗时（秒）

例如应从代理指标或访问日志取得速率和耗时，而不是用网站用户数代替在途请求数。这个关系用于定位并发压力，不自动等于 CPU 占用；突发流量还应单独观察短窗口峰值、排队长度和超时数量。若代理或应用存在已知并发限制，可计算“可用并发余量＝有效上限－峰值在途请求数”，并观察余量缩小时错误率是否同步上升。

容量不足需要证据闭环：同一时段请求量或慢请求增加，连接数、工作进程、CPU、内存、文件描述符等某项资源逼近实际限制，且相应队列或超时随之增加。反过来，若低流量也持续连接失败，或高峰时请求根本没到代理，增加计算资源通常不能修复故障。

修复后应从原失败网络和另一条网络复测域名、HTTPS 与真实业务请求，并核对代理及应用日志中是否还出现同类错误。监控阈值也不宜凭空指定一个统一百分比：先记录正常日与峰值时的请求速率、耗时、错误率和资源使用，找出错误开始持续上升前的余量；再以连续多个采样窗口接近该边界作为预警条件。只有当入口配置正确、故障与负载持续相关，并且优化或限流后余量仍不足时，才把扩容列为触发动作。