CentOS Stream 9香港服务器跨境访问延迟高，如何分层定位链路与系统问题？

在香港服务器部署 CentOS Stream 9 后，跨境访问延迟高并不等于服务器本身性能不足。页面打开慢，可能来自本地网络、DNS 解析、IPv4/IPv6 地址选择、跨境路由、链路丢包、服务器资源等待，也可能只是应用在等待后端接口。ping 的结果只能说明 ICMP 往返情况，不能单独证明网页访问或业务接口一定慢。

建议按照“访问端与服务器范围确认 → 本地网络 → DNS 与地址族 → 路由 → 丢包与 TCP 重传 → 服务器负载 → 应用响应”的顺序排查。每一层都要保留测试时间、目标 IP、协议类型和结果；确认问题层级后再修复，修复完成后使用相同来源、相同目标和相同测试方法复测，避免把不同条件下的结果混在一起。

先确认延迟影响的范围

排查前先回答三个问题：

1. 是所有访问端都慢，还是某个办公网络、某台终端慢？
2. 是首次解析慢、建立连接慢，还是连接建立后等待页面响应慢？
3. 延迟是持续升高，还是只有特定时间段、特定接口或高峰期出现？

可以先整理一份故障记录：

同一个域名可能同时返回多个 IPv4 或 IPv6 地址。不同访问端、不同时间命中的地址不一定相同，因此不能只测试一次就判断整条链路。

可以先在 CentOS Stream 9 服务器上确认基础环境：

date -Is
hostnamectl
ip -br addr
ip route
cat /etc/resolv.conf
nmcli device status

这些命令只读取信息，不会修改网络配置。如果服务器上缺少排查工具，可以先检查软件包是否存在：

rpm -q bind-utils traceroute mtr sysstat curl

确认缺少后再安装对应工具：

sudo dnf install bind-utils traceroute mtr sysstat curl

安装软件包会更新本机软件包状态，但不会自动重启业务服务。生产环境执行前应确认软件源可用，并按维护窗口管理变更。

第一层：排除本地网络与访问端问题

跨境访问的实际延迟，起点是访问端，而不是香港服务器。访问端的无线网络、办公网出口、终端 DNS、出口防火墙或带宽占用，都可能让服务器看起来“响应很慢”。

先测试本地网关

在受影响的 Linux 访问端执行：

ip route
ping -c 30 <本地网关地址>
ping -c 30 <香港服务器IPv4地址>

如果是 Windows 终端，可以使用：

ping -n 30 <本地网关地址>
ping -n 30 <香港服务器IPv4地址>
tracert -d <香港服务器IPv4地址>

结果可以这样判断：

• 本地网关已经出现明显延迟或丢包：优先检查无线信号、交换机端口、办公网出口和本地带宽，不要先修改服务器。
• 本地网关稳定，但访问服务器的 RTT 明显升高：问题可能出现在出口之后的路由、跨境链路或服务器侧。
• 同一办公网只有一台终端异常：检查该终端的本地 DNS、IPv6、系统防火墙和浏览器环境。
• 同一域名在不同访问网络中表现差异明显：更像是访问路径、出口或地址选择问题，而不是 CentOS Stream 9 内核本身。

如果服务器允许 ICMP，可以从两台或多台终端进行对比。若服务器禁用了 ICMP，ping 失败不能直接判定 TCP 443 不通，应改用 TCP 连接测试和 HTTPS 请求测试。

区分网络 RTT 与业务响应时间

ping 得到的是 ICMP 往返时间。例如 RTT 为 80 毫秒，只说明一个 ICMP 请求和响应完成的时间，不能表示网页一定在 80 毫秒内加载完成。HTTPS 还包含 DNS、TCP 握手、TLS 协商、服务端排队、应用处理和响应传输等环节。

因此，访问端至少要同时保留两类结果：

ping -c 30 <服务器IPv4地址>
curl --connect-timeout 5 --max-time 20 -sS -o /dev/null \
  -w 'remote=%{remote_ip}\nhttp=%{http_code}\nconnect=%{time_connect}\nstarttransfer=%{time_starttransfer}\ntotal=%{time_total}\n' \
  https://www.example.com/health

如果 ping 延迟高，但 curl 的连接和首字节时间基本正常，可能是 ICMP 被限速、降优先级，或者 ICMP 与 TCP 使用了不同路径。此时不能仅凭 ping 结果调整服务器配置。

如果 ping 正常，但 curl 的 time_connect 或 time_starttransfer 明显升高，应继续排查 TCP 路由、TLS、服务端负载和应用响应。

第二层：检查 DNS、IPv4 和 IPv6 地址选择

DNS 问题常被误判为服务器网络延迟。浏览器访问域名时，必须先完成名称解析；如果解析器响应慢、返回了不可达的地址，或者客户端优先选择了质量较差的 IPv6 路径，最终表现就可能是“网站偶尔很慢”。

查看解析耗时和返回地址

在 CentOS Stream 9 上执行：

dig www.example.com A
dig www.example.com AAAA

重点关注：

• Query time：当前 DNS 查询耗时；
• ANSWER SECTION：返回的 IPv4 和 IPv6 地址；
• TTL：记录缓存时间；
• 是否同时存在 A 和 AAAA 记录；
• 多次查询返回的地址是否发生变化。

也可以查看系统实际使用的解析器：

cat /etc/resolv.conf
nmcli device show | grep -E 'IP4.DNS|IP6.DNS'

如果服务器启用了 systemd-resolved，可以进一步检查：

resolvectl status
resolvectl query www.example.com

resolvectl 无法使用不一定代表 DNS 故障。CentOS Stream 9 的网络配置可能由 NetworkManager 直接维护，是否使用 systemd-resolved 要以实际服务状态为准。

分别测试 IPv4 和 IPv6

curl -4 --connect-timeout 5 --max-time 20 -sS -o /dev/null \
  -w 'IPv4 remote=%{remote_ip} connect=%{time_connect} total=%{time_total}\n' \
  https://www.example.com/health

curl -6 --connect-timeout 5 --max-time 20 -sS -o /dev/null \
  -w 'IPv6 remote=%{remote_ip} connect=%{time_connect} total=%{time_total}\n' \
  https://www.example.com/health

判断方式如下：

• IPv4 正常、IPv6 连接超时或明显更慢：检查 AAAA 记录、服务器 IPv6 路由和访问端 IPv6 出口。
• IPv4、IPv6 都慢：继续检查访问端、路由和服务器处理时间。
• DNS 查询慢，但直接连接已经解析出的地址较快：优先处理 DNS 解析链路，不要先调整应用。
• 只有特定 DNS 解析器返回异常地址：检查企业 DNS 转发、缓存或权威记录配置。

使用 --resolve 验证 DNS 是否为根因

直接使用 IP 访问 HTTPS 可能因为 Host 或 SNI 不匹配而得到错误结果。更准确的方式是保留域名，同时强制指定目标 IP：

curl --resolve www.example.com:443:198.51.100.10 \
  --connect-timeout 5 --max-time 20 -sS -o /dev/null \
  -w 'remote=%{remote_ip}\nhttp=%{http_code}\nnamelookup=%{time_namelookup}\nconnect=%{time_connect}\nappconnect=%{time_appconnect}\nstarttransfer=%{time_starttransfer}\ntotal=%{time_total}\n' \
  https://www.example.com/health

198.51.100.10 是示例地址，实际测试时替换为 DNS 返回的真实服务器地址。

如果正常域名访问慢，而 --resolve 指向某个地址后恢复，重点检查：

• DNS 返回的多个地址是否质量不一致；
• 某个 A 或 AAAA 记录是否指向错误目标；
• DNS 缓存是否尚未过期；
• 客户端是否优先使用了一条异常的 IPv6 路径。

不要因为一次 DNS 查询较慢就直接修改 /etc/resolv.conf。该文件可能由 NetworkManager 或其他网络服务生成，手工修改可能在重启网络后失效。若确需调整 DNS，应先保存当前配置，并通过实际管理网络连接的方式修改，验证失败时恢复原解析器。

第三层：使用 traceroute 和 mtr 判断路由变化

当本地网关正常、DNS 地址也正确，但跨境访问仍然延迟高，就要观察从访问端到香港服务器之间的路径。

使用 TCP traceroute 测试业务端口

ICMP traceroute 和实际 HTTPS 流量可能使用不同处理路径。更接近业务场景的测试是 TCP 443：

sudo traceroute -4 -T -p 443 -n <香港服务器IPv4地址>

如果目标使用 IPv6：

sudo traceroute -6 -T -p 443 -n <香港服务器IPv6地址>

参数含义：

• -4 或 -6：指定地址族；
• -T：使用 TCP 探测；
• -p 443：探测 HTTPS 端口；
• -n：不反向解析中间节点名称，避免 DNS 影响显示速度。

若系统不支持 TCP traceroute，也可以使用：

tracepath -n <香港服务器IPv4地址>

traceroute 主要帮助观察路径经过哪些跳点、在哪一跳开始延迟增加。它不能直接证明某个中间节点就是故障点，因为中间路由器可能对探测报文限速或不响应。

用 mtr 观察连续样本

单次 traceroute 是一张路径快照。对间歇性抖动或丢包，应使用有限数量的连续样本：

sudo mtr -r -w -c 50 -T -P 443 <香港服务器IPv4地址>

如果 TCP 探测不可用，可以暂时使用 ICMP：

sudo mtr -r -w -c 50 <香港服务器IPv4地址>

建议在受影响的访问端和香港服务器两侧分别执行。两侧路径可能不对称：访问端到服务器的路径正常，并不代表服务器返回访问端的路径也正常。

典型结果的判断逻辑如下：

不要只截取一条中间跳的高延迟就向线路方下结论。至少应保留源地址、目标地址、协议、端口、测试时间、样本数和最终目标结果。

从服务器侧确认路由选择

在服务器上确认到目标地址使用了哪个本地出口：

ip route get <访问端公网IPv4地址>
ip -6 route get <访问端公网IPv6地址>

如果结果显示的出口接口、下一跳或地址族与预期不一致，说明系统路由需要进一步核对。不要在生产环境中直接执行 ip route replace 或随意修改默认路由，这类操作可能立即影响所有业务连接。修改前应保存当前路由和 NetworkManager 连接配置，安排维护窗口，并准备通过控制台或带外方式回滚。

如果多次 MTR 都显示某一方向的路径在固定位置开始恶化，而服务器 CPU、内存、网卡和应用都正常，应把完整样本交给网络服务商或线路维护方分析，而不是通过重启业务服务解决。

第四层：确认丢包是否影响 TCP 和实际请求

丢包是延迟升高的重要原因，但“看到丢包”与“业务发生丢包”不是同一件事。ICMP 可能被限速，TCP 则可能正常；也可能 ICMP 看起来正常，但 HTTPS 的 TCP 重传已经增加。

观察服务器网卡计数器

先找出实际业务网卡：

ip -br link

再查看网卡收发错误和丢弃：

ip -s link show dev <网卡名>

关注以下字段：

• RX errors、TX errors；
• dropped；
• overruns；
• 计数是否在一段时间内持续增加。

这些计数是累计值，单次查看只能作为基线。可以在业务测试前后各记录一次，比较差值：

date -Is
ip -s link show dev <网卡名>
sleep 60
date -Is
ip -s link show dev <网卡名>

如果网卡错误或丢弃持续增加，应检查虚拟网卡状态、宿主机网络、上游端口和实例所在网络环境。不要在没有证据时直接修改 MTU 或重启网络服务。若怀疑路径 MTU，可先执行：

tracepath -n <目标IPv4地址>

确认 PMTU 变化后，再在维护窗口内调整，并先备份 NetworkManager 连接配置。若调整失败，应恢复原 MTU 并重新加载原连接配置。

查看 TCP 重传与连接状态

ss -s
nstat -az | grep -E 'TcpRetransSegs|TCPTimeouts|TCPRcvQDrop'

也可以查看一段时间内的 TCP 统计：

sar -n TCP,ETCP 1 5

其中 TCP 重传计数需要结合采样时间解释。累计值较大，不一定说明当前故障；如果在相同业务请求期间，重传增量明显增加，并且客户端出现连接重试、超时或 curl 失败，才更能说明链路质量正在影响业务。

观察监听端口的接收队列：

ss -lnt

如果某个监听端口的 Recv-Q 长时间接近队列上限，可能是服务进程来不及接受连接、进程繁忙或连接并发过高。此时应与应用进程、CPU 和请求量同时对照，不能仅凭一次输出扩大队列。

把 ICMP 丢包与业务丢包分开

可以使用下面的逻辑进行交叉验证：

1. ping 有少量丢包，但 HTTPS 请求成功率、TCP 重传和应用超时没有变化：优先怀疑 ICMP 被限速。
2. ping 和 TCP 443 探测都出现丢包，且 curl 总耗时抖动或超时：更像实际链路质量问题。
3. MTR 的中间节点丢包，但最终目标无丢包：不要直接把中间节点认定为故障。
4. 最终目标持续丢包，同时服务器网卡计数器和 TCP 重传增加：检查服务器接入、上游网络和目标方向。
5. 只有一个客户端丢包，其他访问端正常：优先检查该客户端到出口的链路。

第五层：检查 CentOS Stream 9 服务器资源

如果路由和丢包没有异常，就要确认服务器是否因为 CPU、内存、磁盘 I/O、连接队列或宿主机争用导致响应变慢。

CPU、内存和调度压力

uptime
free -h
vmstat 1 5
top -b -n 1 | head -n 30

重点观察：

• load average 是否持续高于可用 CPU 规模；
• vmstat 中 r 是否长期较高；
• si、so 是否持续非零，表示发生交换；
• %wa 是否持续升高，表示进程在等待 I/O；
• %st 是否明显增加，表示虚拟化环境中存在宿主机 CPU 争用迹象；
• 是否有单个进程持续占用 CPU。

负载平均值不能脱离 vCPU 数量判断。例如，4 个 vCPU 上短暂出现 load 5，不一定代表业务已经不可用；如果 r 长时间高于可运行 CPU 数量，同时应用首字节时间同步升高，才更像 CPU 调度压力。

磁盘 I/O 和进程级定位

如果已安装 sysstat，可以执行：

iostat -xz 1 5
pidstat -dur 1 5

判断方向：

• 磁盘利用率长时间接近饱和、等待时间上升：应用可能在等待日志、缓存或其他文件 I/O；
• CPU 空闲较多，但请求仍然慢：继续看 I/O、网络和后端依赖；
• 单个应用进程 CPU 高：确认是否为请求量、日志量、压缩、加密或程序异常；
• 内存不足并伴随 swap 活动：可能造成请求排队和长尾延迟。

不要因为一次高峰输出就立即重启服务或清理缓存。重启会中断连接，清理缓存还可能造成后续请求集中回源。应先记录进程、时间段、请求量和错误日志，再根据服务的发布和回滚流程处理。

查看内核和服务异常

journalctl -k --since "30 min ago" --no-pager
journalctl --since "30 min ago" -p warning..alert --no-pager

如果使用 Nginx 作为 HTTPS 接入层：

systemctl status nginx --no-pager
journalctl -u nginx --since "30 min ago" --no-pager

如果使用其他应用服务，把 nginx 替换为实际服务名。重点检查：

• worker 进程反复退出；
• 文件描述符不足；
• 上游连接失败；
• TLS 握手错误；
• 连接队列、超时或大量 5xx；
• 服务重载或配置变更是否与故障时间一致。

读取日志不会改变系统状态。涉及修改服务配置时，先备份文件并执行语法检查；检查失败时不要重载服务。

第六层：拆解 HTTPS 和应用响应时间

当网络 RTT、路由和服务器资源都没有明显异常，最容易被忽略的是应用本身。一次 HTTPS 请求至少可以拆成 DNS、TCP、TLS、等待首字节和接收完整响应几个阶段。

使用 curl 查看分段耗时

curl --connect-timeout 5 --max-time 20 -sS -o /dev/null \
  -w 'remote_ip=%{remote_ip}\nhttp_code=%{http_code}\n'\
'time_namelookup=%{time_namelookup}\n'\
'time_connect=%{time_connect}\n'\
'time_appconnect=%{time_appconnect}\n'\
'time_pretransfer=%{time_pretransfer}\n'\
'time_starttransfer=%{time_starttransfer}\n'\
'time_total=%{time_total}\n' \
  https://www.example.com/health

为便于阅读，也可以使用单行格式：

curl --connect-timeout 5 --max-time 20 -sS -o /dev/null \
  -w 'ip=%{remote_ip} code=%{http_code} dns=%{time_namelookup}s connect=%{time_connect}s tls=%{time_appconnect}s ttfb=%{time_starttransfer}s total=%{time_total}s\n' \
  https://www.example.com/health

字段含义和判断方式如下：

time_starttransfer 不是纯粹的应用执行时间，它包含请求从客户端到服务器的往返以及服务器开始返回数据前的等待。判断应用慢时，应同时对照服务器访问日志、应用日志和资源指标。

建议分别测试一个静态资源、一个轻量健康检查接口和一个真实业务接口：

for path in /health /static/test.txt /api/example; do
  curl --connect-timeout 5 --max-time 20 -sS -o /dev/null \
    -w "$path code=%{http_code} ttfb=%{time_starttransfer}s total=%{time_total}s\n" \
    "https://www.example.com$path"
done

如果健康检查和静态文件很快，真实 API 的首字节时间明显更高，常见原因包括：

• 应用线程或协程池排队；
• 后端连接池不足；
• 数据查询或远程依赖耗时；
• 应用在等待锁、队列或文件 I/O；
• 动态响应计算量过高。

如果所有路径的 time_connect 都偏高，优先回到路由和链路层；如果 time_connect 正常而 time_starttransfer 高，网络通常不是第一嫌疑。

在 Nginx 日志中记录请求耗时

如果业务使用 Nginx 作为接入或反向代理层，可以增加带耗时字段的日志格式。修改前先备份配置，并确认当前配置中确实存在 http 配置上下文：

log_format timing '$remote_addr - $host [$time_iso8601] '
                  '"$request" $status $body_bytes_sent '
                  'rt=$request_time '
                  'uct=$upstream_connect_time '
                  'uht=$upstream_header_time '
                  'urt=$upstream_response_time';

其中：

• request_time：Nginx 从接收请求到完成响应的时间；
• upstream_connect_time：连接后端的耗时；
• upstream_header_time：等待后端响应头的耗时；
• upstream_response_time：后端响应处理耗时。

配置修改后执行：

sudo nginx -t

只有语法检查通过，才按维护流程重载：

sudo systemctl reload nginx

如果 nginx -t 失败，不要重载；恢复此前备份的配置并重新检查。日志格式变更通常不会改变请求处理逻辑，但会增加少量日志写入，应结合磁盘空间和日志轮转策略执行。

用结果树快速定位根因

将各层结果放在一起，通常可以形成以下判断：

这张表不能替代连续样本，但可以避免把所有延迟都归因于服务器配置。

修复后的验证方法

修复后不要只重新执行一次 ping。应尽量保持以下条件不变：

• 同一个访问端；
• 同一个目标域名和目标 IP；
• 同一个地址族；
• 同一个端口；
• 相近的时间窗口；
• 相同的请求路径；
• 相同或相近的测试样本数。

验证 DNS

连续查询多次，并记录返回地址和查询耗时：

for i in $(seq 1 5); do
  date -Is
  dig www.example.com A +stats | grep -E 'status:|Query time:|ANSWER SECTION:|IN[[:space:]]+A[[:space:]]'
  sleep 2
done

如果修改了 DNS 记录，旧 TTL 尚未到期时，不同解析器仍可能返回旧结果。应同时验证实际业务访问，而不是只看权威记录。

验证路由和丢包

使用与修复前相同的目标和协议：

sudo mtr -r -w -c 50 -T -P 443 <香港服务器IPv4地址>

重点看最终目标的丢包、平均 RTT、最大 RTT 和波动，而不是只看单个中间节点。

验证 HTTPS 分段耗时

for i in $(seq 1 10); do
  date -Is
  curl --connect-timeout 5 --max-time 20 -sS -o /dev/null \
    -w 'ip=%{remote_ip} code=%{http_code} connect=%{time_connect}s ttfb=%{time_starttransfer}s total=%{time_total}s\n' \
    https://www.example.com/health
  sleep 1
done

比较修复前后的成功率、连接时间、首字节时间和总时间。不要只比较平均值，也要观察是否仍有少数请求出现明显长尾。

验证服务器资源

在复测期间同步观察：

vmstat 1 10
iostat -xz 1 10
ss -s
ip -s link show dev <网卡名>

如果网络延迟恢复，但服务器 CPU、I/O 或 TCP 重传仍然持续异常，说明可能存在尚未处理的系统或应用问题。相反，如果服务器指标稳定、业务请求仍慢，应该继续把重点放在访问路径、DNS 地址选择和应用外部依赖上。

建立可持续的复发监控

一次排查解决的是当前故障，持续监控才能判断问题是否复发。建议至少保留以下监控点：

• 从实际业务访问端监控 DNS 解析时间；
• 分别记录 IPv4 和 IPv6 的 TCP 连接时间；
• 记录 TLS 完成时间、首字节时间和完整响应时间；
• 对关键目标定期采集 TCP 443 的路由和丢包样本；
• 服务器侧监控 CPU、load、内存、swap、I/O wait 和网卡错误；
• 记录 TCP 重传增量，而不是只看累计总数；
• 应用侧记录请求量、超时率、5xx 比例、接口首字节时间和后端耗时；
• 每条异常记录关联时间、目标 IP、地址族、请求路径和发布变更。

告警不宜只依据一次 ICMP 超时触发。更合理的方式是要求连续多个样本异常，并同时参考 TCP 请求成功率、最终目标丢包和应用响应时间。这样既能减少中间路由器 ICMP 限速造成的误报，也能更快区分本地网络、跨境链路、CentOS Stream 9 系统资源和应用处理之间的真实边界。