摘要网站出现访问缓慢、部分地区无法打开或 CDN 回源异常时问题可能位于 DNS 解析、TCP 连接、TLS 握手、HTTP 响应、运营商线路或源站应用等不同环节。本文整理一套可复用的分层排查流程结合dig、curl、ping、mtr和dnspup多节点检测的方法帮助站长及运维人员更准确地定位故障范围。一、建立分层排查思路一次完整的网站访问通常包含以下过程用户请求 → DNS 解析 → 建立 TCP 连接 → TLS 握手 → 发送 HTTP 请求 → CDN 或源站处理 → 返回页面内容任何一个环节出现异常都可能表现为“网站访问慢”。因此排查时不应只执行一次ping也不建议在没有确定原因前反复重启服务器。更合理的方法是逐层确认服务器状态 → DNS 解析 → TCP/TLS 连接 → HTTP 响应 → 网络路由 → CDN 与源站二、确认服务器基础状态首先登录服务器检查 CPU、内存和磁盘top free -h df -h继续检查服务器监听端口ss -lntp重点确认CPU 是否长期满载可用内存是否不足磁盘空间是否耗尽80 和 443 端口是否正常监听Web 服务进程是否运行云服务器安全组是否放行端口如果服务器内部资源正常再继续检查网络链路。三、检查 DNS 解析使用dig查看域名当前解析结果dig short example.com指定不同公共 DNS 进行对比dig 1.1.1.1 example.com dig 8.8.8.8 example.com dig 223.5.5.5 example.com需要关注不同 DNS 返回的 IP 是否一致是否仍然返回已经停用的旧 IPCNAME 是否正确指向 CDNTTL 是否过长IPv4 和 IPv6 解析是否符合预期分线路解析是否配置正确查看完整解析过程dig example.com如果刚修改过解析记录部分地区仍然访问旧服务器通常是递归 DNS 或本地缓存尚未过期。四、拆分 HTTP 请求耗时网站打开慢不一定是网络问题也可能是后端程序或数据库响应较慢。可以使用curl拆分各阶段耗时curl -o /dev/null -s -w \ DNS: %{time_namelookup}s\nTCP: %{time_connect}s\nTLS: %{time_appconnect}s\nTTFB: %{time_starttransfer}s\nTOTAL: %{time_total}s\n \ https://example.com各指标含义如下指标含义异常时重点检查DNS域名解析耗时DNS 服务、缓存和线路解析TCP建立连接耗时网络线路、防火墙和安全组TLSHTTPS 握手耗时证书、加密套件和链路延迟TTFB首字节响应时间后端程序、数据库和 CDN 回源TOTAL完整请求耗时页面资源、带宽和服务器性能如果 TCP 时间正常但 TTFB 明显偏高问题通常位于应用程序、数据库或第三方接口而不是网络线路。五、检查 HTTP 状态码执行curl -I https://example.com常见状态码及排查方向状态码含义排查方向200请求正常继续检查响应耗时301/302页面跳转检查是否循环跳转403访问被拒绝检查防火墙、鉴权和访问规则404资源不存在检查站点目录和路由配置502网关异常检查后端进程和反向代理504网关超时检查回源、后端接口和数据库如果接入了 CDN还需要分别测试 CDN 地址和源站地址判断异常发生在节点、回源链路还是源站。六、正确理解 PING基础检测命令ping -c 10 example.comPING 可以反映基础延迟和丢包但存在明显局限部分服务器会限制 ICMPPING 正常不代表 HTTP 服务正常中间设备可能对 ICMP 限速CDN 对 ICMP 和 HTTP 可能采用不同处理策略因此PING 只能作为辅助指标不能单独作为网站可用性的判断依据。七、使用 MTR 分析路由MTR 可以持续观察每一跳的延迟和丢包。安装命令# Debian / Ubuntu apt install mtr -y # CentOS / Rocky Linux yum install mtr -y执行检测mtr -rwzc 30 example.com分析时重点观察最终节点是否持续丢包延迟是否从某一跳开始持续升高路由是否出现跨网或海外绕行不同运营商的路径是否存在明显差异某个中间节点丢包但后续节点和目标节点正常通常只是该节点限制 ICMP 响应并不代表业务流量真的丢失。八、进行多地区节点检测服务器本地测试正常只能证明当前服务器到目标地址的链路正常。如果用户分布在不同地区还需要从多个节点检测DNS 解析结果PING 延迟HTTP 状态响应时间MTR 路由不同运营商之间的差异可以使用运营商拨测平台或多节点网络检测工具。本文测试时使用的页面为dnspup.com使用多节点结果时不要只看某一个异常节点而应关注异常是否具有地区性、运营商集中性和持续性。九、常见故障判断情况一不同节点解析到不同 IP检查DNS 分线路配置CDN 调度策略TTL 和缓存是否残留旧记录IPv4 和 IPv6 记录情况二DNS 一致但部分地区延迟较高继续检查 MTR是否存在跨运营商绕路是否经过海外节点延迟从哪一跳开始升高终点是否存在持续丢包情况三PING 正常但 HTTP 返回 502 或 504重点检查CDN 回源配置源站端口Nginx 反向代理后端服务状态防火墙和安全组数据库及接口超时情况四连接正常但首字节时间很长优先检查PHP、Java、Node.js 等后端程序MySQL 慢查询Redis 连接第三方 API动态页面缓存CDN 回源时间十、宝塔环境下的补充检查检查 Nginx 配置nginx -t重新加载配置nginx -s reload检查服务日志tail -n 100 /www/wwwlogs/example.com.log tail -n 100 /www/wwwlogs/example.com.error.log如果使用 CDN需要确认回源 IP 是否正确回源协议是否一致源站证书是否有效CDN 节点是否被防火墙拦截是否启用了错误的强制跳转源站是否限制访问 Host总结排查网站访问异常时可以按照下面的顺序执行检查服务器资源 → 确认端口和服务 → 对比 DNS 解析 → 拆分 HTTP 请求耗时 → 检查状态码 → 分析 PING 和 MTR → 对比多个地区节点 → 检查 CDN 与源站分层排查的核心是先确定问题位于解析、网络、传输还是应用层再针对具体环节处理。这样可以减少无效操作也能更快定位区域性访问异常。
从 DNS 解析到 MTR 路由：如何系统定位网站访问慢与区域性故障
摘要网站出现访问缓慢、部分地区无法打开或 CDN 回源异常时问题可能位于 DNS 解析、TCP 连接、TLS 握手、HTTP 响应、运营商线路或源站应用等不同环节。本文整理一套可复用的分层排查流程结合dig、curl、ping、mtr和dnspup多节点检测的方法帮助站长及运维人员更准确地定位故障范围。一、建立分层排查思路一次完整的网站访问通常包含以下过程用户请求 → DNS 解析 → 建立 TCP 连接 → TLS 握手 → 发送 HTTP 请求 → CDN 或源站处理 → 返回页面内容任何一个环节出现异常都可能表现为“网站访问慢”。因此排查时不应只执行一次ping也不建议在没有确定原因前反复重启服务器。更合理的方法是逐层确认服务器状态 → DNS 解析 → TCP/TLS 连接 → HTTP 响应 → 网络路由 → CDN 与源站二、确认服务器基础状态首先登录服务器检查 CPU、内存和磁盘top free -h df -h继续检查服务器监听端口ss -lntp重点确认CPU 是否长期满载可用内存是否不足磁盘空间是否耗尽80 和 443 端口是否正常监听Web 服务进程是否运行云服务器安全组是否放行端口如果服务器内部资源正常再继续检查网络链路。三、检查 DNS 解析使用dig查看域名当前解析结果dig short example.com指定不同公共 DNS 进行对比dig 1.1.1.1 example.com dig 8.8.8.8 example.com dig 223.5.5.5 example.com需要关注不同 DNS 返回的 IP 是否一致是否仍然返回已经停用的旧 IPCNAME 是否正确指向 CDNTTL 是否过长IPv4 和 IPv6 解析是否符合预期分线路解析是否配置正确查看完整解析过程dig example.com如果刚修改过解析记录部分地区仍然访问旧服务器通常是递归 DNS 或本地缓存尚未过期。四、拆分 HTTP 请求耗时网站打开慢不一定是网络问题也可能是后端程序或数据库响应较慢。可以使用curl拆分各阶段耗时curl -o /dev/null -s -w \ DNS: %{time_namelookup}s\nTCP: %{time_connect}s\nTLS: %{time_appconnect}s\nTTFB: %{time_starttransfer}s\nTOTAL: %{time_total}s\n \ https://example.com各指标含义如下指标含义异常时重点检查DNS域名解析耗时DNS 服务、缓存和线路解析TCP建立连接耗时网络线路、防火墙和安全组TLSHTTPS 握手耗时证书、加密套件和链路延迟TTFB首字节响应时间后端程序、数据库和 CDN 回源TOTAL完整请求耗时页面资源、带宽和服务器性能如果 TCP 时间正常但 TTFB 明显偏高问题通常位于应用程序、数据库或第三方接口而不是网络线路。五、检查 HTTP 状态码执行curl -I https://example.com常见状态码及排查方向状态码含义排查方向200请求正常继续检查响应耗时301/302页面跳转检查是否循环跳转403访问被拒绝检查防火墙、鉴权和访问规则404资源不存在检查站点目录和路由配置502网关异常检查后端进程和反向代理504网关超时检查回源、后端接口和数据库如果接入了 CDN还需要分别测试 CDN 地址和源站地址判断异常发生在节点、回源链路还是源站。六、正确理解 PING基础检测命令ping -c 10 example.comPING 可以反映基础延迟和丢包但存在明显局限部分服务器会限制 ICMPPING 正常不代表 HTTP 服务正常中间设备可能对 ICMP 限速CDN 对 ICMP 和 HTTP 可能采用不同处理策略因此PING 只能作为辅助指标不能单独作为网站可用性的判断依据。七、使用 MTR 分析路由MTR 可以持续观察每一跳的延迟和丢包。安装命令# Debian / Ubuntu apt install mtr -y # CentOS / Rocky Linux yum install mtr -y执行检测mtr -rwzc 30 example.com分析时重点观察最终节点是否持续丢包延迟是否从某一跳开始持续升高路由是否出现跨网或海外绕行不同运营商的路径是否存在明显差异某个中间节点丢包但后续节点和目标节点正常通常只是该节点限制 ICMP 响应并不代表业务流量真的丢失。八、进行多地区节点检测服务器本地测试正常只能证明当前服务器到目标地址的链路正常。如果用户分布在不同地区还需要从多个节点检测DNS 解析结果PING 延迟HTTP 状态响应时间MTR 路由不同运营商之间的差异可以使用运营商拨测平台或多节点网络检测工具。本文测试时使用的页面为dnspup.com使用多节点结果时不要只看某一个异常节点而应关注异常是否具有地区性、运营商集中性和持续性。九、常见故障判断情况一不同节点解析到不同 IP检查DNS 分线路配置CDN 调度策略TTL 和缓存是否残留旧记录IPv4 和 IPv6 记录情况二DNS 一致但部分地区延迟较高继续检查 MTR是否存在跨运营商绕路是否经过海外节点延迟从哪一跳开始升高终点是否存在持续丢包情况三PING 正常但 HTTP 返回 502 或 504重点检查CDN 回源配置源站端口Nginx 反向代理后端服务状态防火墙和安全组数据库及接口超时情况四连接正常但首字节时间很长优先检查PHP、Java、Node.js 等后端程序MySQL 慢查询Redis 连接第三方 API动态页面缓存CDN 回源时间十、宝塔环境下的补充检查检查 Nginx 配置nginx -t重新加载配置nginx -s reload检查服务日志tail -n 100 /www/wwwlogs/example.com.log tail -n 100 /www/wwwlogs/example.com.error.log如果使用 CDN需要确认回源 IP 是否正确回源协议是否一致源站证书是否有效CDN 节点是否被防火墙拦截是否启用了错误的强制跳转源站是否限制访问 Host总结排查网站访问异常时可以按照下面的顺序执行检查服务器资源 → 确认端口和服务 → 对比 DNS 解析 → 拆分 HTTP 请求耗时 → 检查状态码 → 分析 PING 和 MTR → 对比多个地区节点 → 检查 CDN 与源站分层排查的核心是先确定问题位于解析、网络、传输还是应用层再针对具体环节处理。这样可以减少无效操作也能更快定位区域性访问异常。
