用了几个月甚至几年的服务突然某天早上怎么点都打不开这种经历我相信搞技术的人都遇到过。不是密钥失效不是配置被改也不是服务商跑路但就是莫名其妙连不上。很多时候真正的坑往往藏在最不起眼的地方比如本地缓存、系统时钟或者某个早就过期却没人在意的域名解析记录。这篇文章就从一个典型的“长期稳定运行的服务突然不可用”故障场景出发记录我完整的一次排查过程。不看任何厂商日志不用任何花哨工具就用本机自带命令一步步缩小范围。整个过程适合刚接触网络排查的新手也适合想梳理一下排障思路的运维朋友。我尽量把每一步为什么这么做、每一条命令怎么看结果都写得清清楚楚。1. 故障现场与第一步判断先说现象。当天早上打开公司内部文档系统浏览器转圈转了很久最后直接提示“无法访问此网站”。试了两次都一样。当时我的第一反应不是慌而是先问自己一个问题这个服务到底是彻底挂了还是只有我这边访问不了这个问题决定了后面完全不同的排查方向。我顺手做了三个快速验证用手机开移动数据访问同一个服务域名结果正常打开。用公司另一台电脑访问结果也正常。只有我这台电脑不行。这就很有意思了。服务端大概率没挂问题出在我这台电脑和这个服务之间的某个环节上。很多人这时候喜欢直接重装软件、重启电脑、或者干脆卸载重装我建议先别急。重装是最后手段因为它会把问题吃掉但不会告诉你问题在哪。下次再出问题你还是两眼一抹黑。接下来我做的事情是把“访问不了”这个模糊的描述细化成一个可定位的技术现象。我打开浏览器手动输入服务的完整地址观察返回内容是浏览器报错还是页面返回了503/504是连接超时还是被重置是解析不到域名还是跳到某个奇怪的错误页这些细节看起来琐碎实际排查时却是最有力的线索。比如“连接被重置”和“连接超时”的成因完全不同前者通常是中间设备干预后者通常是路由不可达或服务端无响应。如果连这些信息都不记录后面很容易在原地打转。我在纸上写下了几个关键词解析结果、连通性、路由路径。然后开始按从下往上的顺序逐层排查。2. 从终端开始逐层排查2.1 先确认本机网络出口是好的排障最忌讳上来就盯着目标服务看。第一步应该是确认你本机到互联网的链路是不是通的。如果连外网都没通后面查什么都白搭。我在终端里执行了两个命令ping 127.0.0.1这个命令检查本机协议栈基本没问题。通的话说明网卡和TCP/IP协议栈至少还在正常工作。然后我再ping网关ping 192.168.1.1这是局域网内最基础的一条链路。如果网关都不通问题基本锁定在网卡、网线、Wi-Fi信号或者路由器本身。但这次我本机到网关是通的延迟1ms很稳定。然后ping一个公共地址比如ping 223.5.5.5注意这里我刻意选了一个IP地址而不是域名。原因后面会讲。如果IP能通而域名不通说明问题出在DNS解析如果IP也不通那就是路由出口的问题。这次ping 223.5.5.5是通的说明我本机到公网出口完全正常。到这里可以把范围从“我的电脑坏了”缩小到“我的电脑与目标服务之间的某个环节有问题”。别小看这个判断它帮你排除掉了网线、网卡、路由器、运营商接入这五层问题下面只需要盯着和目标服务相关的东西看。2.2 域名解析最容易暴雷的环节既然外网通了接下来要确认的就是域名解析。很多服务用了好几年突然“不行”大概率是DNS换了IP、本地DNS缓存陈旧、或者你偶尔手动配过hosts。我用nslookup查看解析结果nslookup docs.example.com返回了一个A记录但我发现一个问题解析出来的IP地址和我记忆中这个服务该有的IP完全不一样。我印象中它一直是10.20.30.40这种内网地址很多公司内部服务虽然通过公网域名暴露但解析给的是内网IP现在解析结果却变成了一个公网IP 183.x.x.x。这里要补一个常识DNS解析结果不是一成不变的。公司做网络改造、把服务从机房租到云端、或者换了CDN厂商都会导致域名解析的IP发生变化。如果本地DNS缓存更新不及时就会出现“别人家都能访问就我这不行”的诡异现象。我在Mac上清一下DNS缓存sudo dscacheutil -flushcache sudo killall -HUP mDNSResponderWindows对应的是ipconfig /flushdns清完缓存重新nslookup结果还是那个公网IP。那就说明不是缓存问题而是域名本来就已经指向新的IP了。这时候我尝试直接ping这个新IP结果不通。而服务域名在别的电脑上却能正常打开说明这个新IP对我这边的网络路径是异常的。到这一步方向已经完全清晰了不是DNS出错而是“我的网络到新IP”这一段路径有问题。2.3 路由路径找准断点在哪一跳接下来用traceroute看路由走向。Mac或Linux用traceroute -T -p 443 183.x.x.xWindows用tracert 183.x.x.x加-T -p 443是为了直接探测TCP 443端口的连通性比默认的ICMP更贴近真实访问场景因为很多节点禁ping。输出的内容大概是这样前三跳是本地网关和运营商接入设备延迟正常第四跳到某个节点之后请求全部超时出现星号。这种情况有两种可能一是那个节点禁用了探测包不值得恐慌二是那一段路由确实断了需要再确认。怎么确认我换了一个端口再探测一次同时用别的DNS做对比解析确认我本地的路由表中没有奇怪的静态路由。比如route -n get 183.x.x.x这条命令能看到去往那个IP实际的下一跳是什么。结果显示下一跳就是默认网关没有异常。那就说明不是本机路由表被改过问题出在本地出口之外的网络路径上。这个时候我基本可以断定域名解析出来的新IP在我当前所处网络的运营商路由里存在异常或者目标服务做了区域访问限制。我在第1章已经验证过“手机用移动数据能访问”也就是说换个网络出口就能通进一步坐实了“本地出口与目标IP之间存在路径问题”这一判断。3. 服务端状态也不能放过3.1 先看端口监听与访问策略虽然基本锁定是网络路径问题但作为负责任的排查服务端状态我还是看了一眼。有时候问题不是一个而是叠加的。我先检查目标服务在内网测试环境里的监听状态。常用的方式有netstat -tlnp | grep 443如果是Windows服务器netstat -ano | findstr :443LISTENING状态的监听就是正常的如果看不到443端口说明Web服务进程根本没起来或者被防火墙拦了。但这次服务端没问题端口正常监听防火墙也放行了我的来源IP。3.2 证书过期最容易忽略的定时炸弹第二个容易忽略的检查项是TLS证书有效期。很多服务跑着跑着突然浏览器报警但后台看起来一切正常。我习惯用openssl直接看证书到期时间根本不用打开浏览器openssl s_client -connect docs.example.com:443 -servername docs.example.com /dev/null | openssl x509 -noout -dates这条命令会把服务器返回的证书起始日期和结束日期打出来。如果结束日期已经过去了那就说明服务端没做证书自动续期坑了所有访问者。这次我看了证书还有两百多天没问题。不过这里有个细节提醒一下如果服务端证书是新的但你本机系统时间不对——比如主板电池没电导致系统时间退回了几年前——那么就算证书本身没过期浏览器也会当作过期处理。因为TLS证书校验依赖两端时间同步客户端时间不在证书有效期内握手就会失败。这个坑我踩过一次排查了半小时才发现是本地时间错了。3.3 服务日志里的线索服务端日志这时反而没有太多参考价值因为从日志上看我这边的请求根本没有到达服务端。这就是“路径异常”和“服务故障”最明显的区别路径异常时服务端日志里干干净净什么都没收到。而服务故障时日志里会有大把的连接尝试、错误堆栈、超时记录。我翻了翻最近几天的访问日志发现从我这根运营商线路来的请求全都断在了中间环节一次都没有进到后端。这也正常毕竟我已经通过traceroute确认断点在中间链路。4. 中间链路、本地环境与终端小问题4.1 路由器与运营商的“隐形故障”既然问题不在我本机也不在服务端那中间链路还有什么值得看的首先是家里或者办公网络的路由器。老路由长时间通电后NAT表项可能会变得乱七八糟。我做的第一个操作是把路由器断电重启等两分钟再通电。这一招能解决六成“昨天好好的今天突然不行”的奇怪问题因为很多情况下是连接表被占满或者固件内部状态卡死了。但这次重启路由器后问题依旧。于是我又试着把路由器WAN侧的MTU从1500改成1400。为什么要看MTU因为如果链路中某一段的MTU变小而流量又超过了这个值就可能导致大包被丢弃小包却正常。现象就是网页、视频这类大流量请求卡死而ping这类小包完全正常。虽然最终问题不是出在MTU上但这种排查细节往往是很多人没试过的方向。4.2 浏览器插件和系统代理的暗坑再往上看本地环境里还有一个经常被忽略的环节浏览器扩展和系统代理设置。我打开浏览器设置确认有没有开“自动配置代理”或安装了那种全局接管流量的插件。很多插件会在后台把流量绕路到海外节点或者其他中间服务器一旦那个中间服务出问题你会感觉是目标网站挂了其实是“绕路的车”翻在路上了。这种干扰特别隐蔽因为页面加载失败时浏览器报的错误和真正的网络不通几乎一模一样。我习惯在排查早期就直接关闭所有扩展用无痕模式打开同一个地址。如果无痕模式下能访问那基本可以断定是某个扩展干的“好事”。这次测下来无痕模式同样访问不了说明也不是扩展的问题。4.3 公共DNS与本地hosts的排查还有一个高频雷区是hosts文件和DNS配置。我之前遇到过用户把一条过去的解析记录写死在hosts里服务端都换过好几轮IP了他那边每次访问都是找老IP当然永远失败。我在Mac上查看了本地hosts文件cat /etc/hostsWindows就是type C:\Windows\System32\drivers\etc\hosts确认没有写死记录。同时我把本机DNS临时切换到公共DNS比如223.5.5.5和119.29.29.29再尝试访问。这一步是为了排除“本地DNS服务器返回了过期的解析结果”这个可能。切换后依然访问不了但解析IP没变说明目标IP确实就是要访问的那个IP不是DNS故意使坏。5. 问题排查速查表这次排查从开始到定位问题用了将近四十分钟。整个过程踩了不少容易忽略的细节我整理成了一张速查表以后遇到类似场景可以照着过一遍排查项命令或操作正常表现异常时该怎么办本机协议栈ping 127.0.0.1通重启网卡驱动或检查系统网络组件局域网链路ping 网关IP通且延迟低查网线、Wi-Fi信号、路由器公网出口ping 223.5.5.5通路由器重拨号或联系运营商DNS解析nslookup 域名返回正确IP刷新DNS缓存、换公共DNS路由路径traceroute -T -p 443 IP最后一跳可达对比不同网络出口定位断点端口监听netstat -tlnp | grep 443LISTENING启动服务或改防火墙规则证书有效期openssl s_client看dates未过期续期证书本地hostscat /etc/hosts无异常记录删掉或注释异常行浏览器扩展无痕模式访问可访问逐个禁用扩展找问题这张表适合按顺序从第一项执行到最后一项也可以根据已有信息直接跳转到疑点项。我个人经验是不要跳过前两步因为看起来不起眼反而最容易在水落石出前浪费你最多时间。6. 排障经验与心得这次故障排查下来我最大的体会是排障的思路比工具重要。不急着下结论不跳过步骤一层层缩小范围最后一定能把问题定位到具体的链路上。很多时候我们凭直觉直接猜某个环节出问题但如果后续验证不足很容易被表象带偏。我整理几条实用的心得体会排查顺序从“自己能控制的范围”开始再到“自己控制不了的范围”。本机、局域网、出口、DNS、路由、服务端这个顺序每次都不会错。所有的现象都要记录。几点几分出现、报错内容是什么、当时你对系统做了什么变更——这些记录在排障时都是最珍贵的线索。遇到解析IP变了的情况先别急着说“DNS出问题了”。解析结果本身没错错的是缓存、路由或其他环节。多对比几个网络环境就能迅速判断到底是谁的问题。服务端日志没有请求记录不一定代表没有用户访问失败。很多人只盯服务端日志却忽略了“请求根本没到服务端”这种情况。长期不重启的路由器确实可能积累问题但一上来就重启之前至少先看一眼它的状态页。如果状态页也打不开再重启不迟。最后再分享一个小技巧我习惯在桌面备忘录里维护一份“长期服务清单”记录每个服务对应的域名、IP归属、端口、证书到期时间、以及上次维护的日期。真出故障时打开这份清单先对照一遍经常五分钟内就能排除掉一半以上的干扰项。这次我虽然没有第一时间用上但事后把新的IP信息和断点情况补录了进去下次再遇到类似问题比这次会快很多。
