内容摘要：上周三下午，同事老张在群里发了一张截图，浏览器显示“无法访问此网站”，地址栏里是公司刚部署好的内部管理系统。他@了运维小李，问是不是服务器挂了。小李回了一句：“我这儿能打开啊。”然后甩了另一张截图，页

上周三下午，网站同事老张在群里发了一张截图，服务浏览器显示“无法访问此网站”，器上地址栏里是开其开公司刚部署好的内部管理系统。他@了运维小李，电脑打问是网站不是服务器挂了。小李回了一句：“我这儿能打开啊。服务”然后甩了另一张截图，器上页面完整，开其开登录框清晰可见。电脑打同一时间，网站同一个网址，服务两台电脑，器上两种结果。开其开

这事不新鲜。电脑打干过运维或者做过Web开发的人，多少都碰过。问题往往不在服务器本身，而在“谁在访问”和“怎么访问”这两件事上。

先看最直接的一层：DNS。服务器上打开网站，很多时候用的是localhost或者127.0.0.1，这压根不经过DNS解析，直接指向本机。其他电脑要访问，得通过域名或者局域网IP。域名解析有没有生效？本地hosts文件有没有写死一条旧记录？公司内网DNS有没有更新？任何一个环节卡住，结果就是“服务器自己认识自己，别人不认识它”。我见过最离谱的一次，是开发在服务器hosts里把域名指向了127.0.0.1，自己测得好好的，全公司其他人访问全挂。

再往下走，防火墙。服务器上的防火墙规则通常只放行了特定端口，比如80和443。但有些内网系统跑在8080或者3000端口上，服务器本机访问不受限制，外部请求直接被iptables或者Windows防火墙拦掉。还有一种情况：云服务商的安全组。你在服务器上curl自己没问题，但安全组没开对应端口的入站规则，外面的人就是进不来。这个坑我踩过，排查了半天代码，最后发现是阿里云控制台里一条规则没加。

监听地址也值得看一眼。有些服务默认绑定127.0.0.1，只接受本机连接。改成0.0.0.0才能监听所有网卡。Node.js的Express、Python的Flask、Java的Spring Boot，都有类似的配置项。服务器上跑起来觉得一切正常，因为请求确实到了本机回环接口，但局域网里其他机器发来的包，服务根本没在对应网卡上等着接。

代理和VPN是另一个常见变量。老张的电脑可能挂着公司VPN，流量走了另一条隧道，DNS也换了。或者浏览器配了代理，请求压根没到目标服务器。反过来，服务器本身如果配了反向代理，Nginx的server_name没匹配上，或者proxy_pass指错了后端，也会出现“服务器上直接访问后端端口能通，走代理就404”的怪事。

还有一类问题更隐蔽：MTU和网络路径。服务器在云上，其他电脑在办公室，中间经过运营商、防火墙、负载均衡，某个环节的MTU值偏小，大包被丢弃，TCP握手能完成，但页面加载到一半就卡死。这种问题用ping小包测是通的，一传大文件就断。抓包看半天，最后发现是路径MTU发现机制没正常工作。

说回老张那件事。小李后来查了一圈，发现是老张电脑的DNS缓存里还留着旧IP。那个IP是测试环境的一台机器，早下线了。ipconfig /flushdns之后，页面正常打开。服务器没问题，网络没问题，就是缓存没刷新。

这类问题的排查顺序，我自己的习惯是：先确认访问方式是否一致——都用IP还是都用域名；再查DNS解析结果；然后看防火墙和安全组；接着确认服务监听地址；最后抓包看TCP层有没有异常。别一上来就重启服务，多数时候服务本身是好的，只是它没等到那个该来的请求。