用户反馈网站打不开，你第一反应是检查服务器。SSH连上去，负载正常，Nginx在跑，本地curl一下返回200。服务器没问题。但用户那边确实打不开。你让他换个网络试试，他说换了手机热点还是不行。你让他截个图，浏览器显示“无法访问此网站”或者“连接超时”。

　　这时候问题就变得模糊了。服务器是好的，但用户访问不到。问题出在“用户到服务器”这条路上的某个环节。 可能是DNS解析出了问题，也可能是中间某段网络链路故障，还可能是用户的本地网络环境有问题。

　　DNS污染和服务器故障，表象上都是“网站打不开”，但排查方向和解决手段完全不同。判断错了方向，你会在服务器上白折腾几个小时，而真正的问题在DNS层面纹丝不动。

　　先建立一个排查框架：从用户到服务器，中间隔了什么

　　用户访问一个网站，数据包要经过几个环节：

　　第一步，DNS解析。 浏览器向本地DNS服务器查询域名对应的IP地址。这一步如果被污染，用户拿到的是一个错误的IP。

　　第二步，建立TCP连接。 浏览器向解析得到的IP发起TCP连接。这一步如果被阻断，连接无法建立。

　　第三步，TLS握手(HTTPS)。 连接建立后，进行TLS握手，验证证书，协商加密密钥。

　　第四步，HTTP请求-响应。 浏览器发送HTTP请求，服务器返回响应内容。

　　DNS污染发生在第一步。服务器故障可能发生在第三或第四步。中间链路故障可能发生在第二步。

　　判断的关键是定位问题发生在哪一步。

　　DNS污染的典型特征

　　DNS污染的核心表现是：域名解析出来的IP地址是错的。

　　这个“错”有几种形态。一种是解析到一个完全不相关的IP，比如一个保留地址、一个黑洞地址，或者一个攻击者控制的服务器。另一种是解析超时，浏览器等待DNS响应直到超时，然后报“DNS_PROBE_FINISHED_NXDOMAIN”或类似的错误。

　　判断DNS污染最直接的方法是绕过本地DNS，用其他方式查询域名。

　　如果你在服务器上，可以直接用 dig 或 nslookup 向多个公共DNS查询同一个域名：

dig example.com @8.8.8.8
dig example.com @1.1.1.1
dig example.com @223.5.5.5

　　如果多个公共DNS返回的IP地址不一致，或者返回的IP和你服务器实际IP不一致，说明DNS解析环节出了问题。如果所有公共DNS返回的IP都一致且正确，但用户仍然打不开，问题就不在DNS。

　　另一个判断方法是用IP直接访问。如果用户通过 http://你的服务器IP 能访问到网站(或者至少能看到服务器有响应)，但通过域名访问不行，说明DNS解析环节有问题。如果通过IP也访问不了，问题可能出在网络链路或服务器本身。

　　DNS污染还有一个特征：它通常只影响特定域名，不影响其他域名。 如果你在同一个网络环境下，访问其他网站都正常，只有你的域名打不开，而你的域名解析出来的IP又是错的，DNS污染的可能性就很高。

　　服务器故障的典型表现

　　服务器故障的表现和DNS污染完全不同。

　　如果服务器宕机或服务未运行，DNS解析通常是正常的——域名能解析到正确的IP，但TCP连接被拒绝或者超时。浏览器报的是“连接被拒绝”或“连接超时”，而不是“找不到服务器”。

　　如果服务器负载过高或服务无响应，TCP连接可能建立，但HTTP请求迟迟得不到响应。浏览器会一直转圈，最终超时。这时候DNS解析是正常的，IP也是对的。

　　如果服务器只对部分用户不可达，比如防火墙规则误配置、或者安全组只放行了特定IP段，那么受影响用户的DNS解析正常，但TCP连接无法建立。这种情况下，从服务器本地测试一切正常，但从外部特定网络测试就不行。

　　判断服务器故障的关键是从服务器端和从多个外部节点分别测试。

　　在服务器上，检查Nginx/Apache是否在运行，端口是否在监听：

ss -tlnp | grep -E '80|443'

　　从外部节点测试，可以用在线工具(比如各种“网站测速”或“端口检测”服务)或者从其他服务器上用 curl 测试：

curl -I --connect-timeout 10 http://你的域名

　　如果服务器本地正常，但所有外部节点都连不上，问题在服务器的网络配置或上游链路。如果部分外部节点能连、部分不能，问题在中间链路的某个节点。

　　一个容易混淆的情况：DNS解析正常但网站打不开

　　有一种情况会让排查变得复杂：DNS解析是正确的，但用户仍然打不开网站。

　　这时候DNS污染的可能性基本排除，但问题不一定在服务器本身。可能是：

　　中间链路故障。 用户到服务器之间的某段网络出现了拥塞或中断。比如用户走的是某条国际出口，这条出口在特定时段拥塞严重，导致TCP连接超时。这种情况下，从服务器端看一切正常，从其他网络测试也可能正常，只有特定用户、特定时段出现问题。

　　TCP阻断。 某些网络环境会对特定IP或端口的TCP连接进行阻断。DNS解析正常，但TCP握手无法完成。表现和服务器宕机很像，但服务器本身是好的。

　　TLS握手失败。 如果HTTPS证书过期、配置错误、或者中间设备对TLS握手进行了干扰，浏览器可能在TLS阶段报错。这时候DNS正常，TCP连接也能建立，但HTTPS访问失败。

　　区分这些情况的方法是分步骤测试：先确认DNS解析是否正确，再确认TCP连接能否建立，再确认TLS握手是否成功，最后确认HTTP响应是否正常。

　　用 curl 可以一次性完成这些检查：

curl -v --connect-timeout 10 https://你的域名

　　-v 参数会输出详细的连接过程。你能看到DNS解析结果、TCP连接是否成功、TLS握手是否完成、HTTP响应状态码是什么。哪一步报错，问题就在哪一步。

　　具体的判断流程：

　　第一步，让用户提供具体的错误信息。 浏览器显示的报错文字很关键。“DNS_PROBE_FINISHED_NXDOMAIN”指向DNS问题，“ERR_CONNECTION_TIMED_OUT”指向连接超时，“ERR_CONNECTION_REFUSED”指向服务未运行，“ERR_SSL_PROTOCOL_ERROR”指向TLS问题。

　　第二步，让用户用IP直接访问。 如果IP能访问、域名不能，DNS问题。如果IP也不能，往下走。

　　第三步，从多个外部节点测试。 用在线工具或者从其他服务器上测试域名和IP。如果多个节点都连不上，问题在服务器或上游链路。如果只有用户那边连不上，问题在用户到服务器之间的某段链路。

　　第四步，在服务器上检查服务状态。 确认Web服务在运行，端口在监听，防火墙规则没有误封。

　　第五步，如果以上都正常，但用户仍然打不开，考虑DNS污染。 让用户换一个DNS服务器(比如从运营商DNS换成公共DNS)，看是否能解析到正确的IP。如果换了DNS就好了，说明原来的DNS被污染了。

　　常见问答

　　问：DNS污染和DNS劫持有什么区别?

　　DNS劫持的范围更广，可以是运营商或路由器直接篡改你的DNS设置，把你的查询导向他们指定的服务器;DNS污染特指在DNS查询-响应过程中，通过伪造响应包抢先注入错误结果。污染是劫持的一种技术手段，但劫持不一定是通过污染实现的。对普通用户来说，两者的表现都是“域名解析到了错误的IP”，排查方法类似。

　　问：我用 ping 域名能通，但浏览器打不开，是DNS污染吗?

　　不一定。ping 通说明DNS解析基本正常，ICMP协议能到达目标。但浏览器访问走的是TCP和HTTP/HTTPS，如果TCP连接被阻断、或者TLS握手失败，ping 通但浏览器打不开是可能的。这时候问题不在DNS，在传输层或应用层。

　　问：服务器本地 curl 域名返回200，但外部用户打不开，怎么判断是DNS问题还是链路问题?

　　在服务器上 curl 走的是本机解析，不经过外部DNS。要让用户用 nslookup 或 dig 查询域名，看解析结果是否正确。如果解析结果错误，DNS问题。如果解析结果正确但连不上，用 traceroute 或 mtr 从用户端追踪到服务器IP的路径，看在哪一跳出现了丢包或超时。

　　问：换了DNS服务器就能访问，是不是说明原来的DNS被污染了?

　　大概率是。如果换用公共DNS后解析结果正确、网站能访问，而原来的运营商DNS返回的是错误IP，说明原来的DNS服务器被污染或配置有误。但也要注意，有时候运营商DNS只是缓存了过期的记录，不一定是被恶意污染。

　　问：网站被DNS污染了，我能做什么?

　　如果你是被动受到影响的一方，能做的事情有限。换用加密DNS(DoH/DoT)可以防止本地查询被篡改，但如果污染发生在递归服务器层面，加密DNS只能保护“你到递归服务器”这一段，不能改变递归服务器本身返回错误结果。对于面向公众的服务，可以考虑使用多个域名、或者通过CDN分散入口。根本的解决需要DNS层面的治理，这不是单个网站运营者能控制的。