VPN 已连接但网页还是打不开，先用症状分诊，再按 DNS、IPv6、MTU 三步自查
客户端明明显示“已连接”，浏览器里网页却一直转圈，或者打开一半就停住，这种情况让很多人怀疑是线路坏了，于是不停切换节点。实际上，“已连接”只说明隧道建立成功，并不保证之后每一个环节都通畅。域名解析（DNS）、IPv4 与 IPv6 的走向、数据包大小（MTU）这三处，任何一处出问题，都会出现“已连接却打不开”的现象，而且它们各自有很典型的症状。本文先给一张分诊表，帮你用两分钟判断更像哪一类，再逐项给出可以自己动手的检查方法。所有命令均为系统自带，不需要安装额外工具。
先分诊：三类问题的典型表现
| 看到的现象 | 更可能的环节 | 一句话验证 |
|---|---|---|
| 提示找不到服务器，或者网址一直解析不出来，但用 IP 地址能访问 | DNS | 换一个解析服务器再查同一个域名 |
| 部分网站正常，部分网站转圈，换成同一网站的另一个协议后好转 | IPv6 | 用 curl 分别指定 IPv4 和 IPv6 访问同一网站 |
| 小页面、文字能打开，图片多、页面大或上传时卡住 | MTU | 用带“禁止分片”的 ping 测最大包长 |
三类症状可以叠加，但先判断出最像哪一类，就不必三项全部做一遍。
第一步：DNS，域名有没有被正确解析
怎么判断 DNS 出了问题？
最直接的对比是：同一个域名，用系统默认解析和指定的公共解析服务器各查一次。命令行输入 nslookup example.com 查看系统默认的结果，再输入 nslookup example.com 1.1.1.1 指定另一个解析服务器。如果默认解析超时、报错或返回的地址和指定服务器差异很大，说明解析这一环有问题；如果两者结果一致，DNS 大概率不是原因。还可以看响应时间，解析动辄需要好几秒，网页自然会“转圈”很久。
DNS 有问题时怎么处理？
先清掉本机缓存：Windows 使用 ipconfig /flushdns，macOS 使用 sudo dscacheutil -flushcache; sudo killall -HUP mDNSResponder。然后检查系统或客户端中使用的解析服务器是不是运营商默认的那一个，可以临时改成公共解析服务器再试。有些客户端会接管 DNS 设置，改动之后如果没有生效，要在客户端自己的设置里确认，而不是只改系统设置。改完再用上面的两条 nslookup 复测一遍，才算真正验证过。
第二步：IPv6，双栈网络里容易被忽略的一环
为什么 IPv6 会让页面时通时不通？
现在很多网站和家用宽带同时提供 IPv4 与 IPv6。系统在访问时通常会优先尝试 IPv6，如果 IPv6 那条路径实际不通，需要等它超时后才会回退到 IPv4，表现就是网页要等很久才打开，或者不同网站表现不一致。当隧道只处理了 IPv4 流量、而 IPv6 流量仍走本地网络时，这种不一致会更明显。
怎么用 curl 验证？
对同一个网站分别强制使用两种协议，比较结果和耗时：
- 输入
curl -4 -sS -o /dev/null -w "%{http_code} %{time_total}\n" https://www.example.com，强制走 IPv4，记录状态码和耗时。 - 输入同样的命令，把
-4改成-6，强制走 IPv6。 - 如果 IPv4 很快而 IPv6 超时或报错，问题基本锁定在 IPv6；可以在系统网络设置里临时禁用 IPv6 再测，网页恢复正常就能确认。
需要说明的是，禁用 IPv6 只是用来验证的临时手段，而不是长期方案。如果你的客户端提供了对 IPv6 的处理选项，优先在客户端里调整，长期关闭系统级 IPv6 可能影响其他依赖它的应用。
第三步：MTU，小页面能开、大页面卡住的常见原因
MTU 是什么，为什么隧道会让它变小？
MTU（最大传输单元）指网络链路单次能传输的最大数据包长度，以太网上的常见默认值是 1500 字节。隧道会在原始数据包外面再包一层头部，占用额外字节，于是能留给数据本身的空间变小。如果隧道两端的设置没有相应调小，超过实际上限的大包就会被丢弃或被要求分片，表现为小请求正常，图片、大页面和上传却卡住。
怎么用 ping 测出可用的最大包长？
用带“禁止分片”标志的 ping，从大包开始逐步减小，找到刚好能通过的长度：
- Windows：
ping -f -l 1472 8.8.8.8 - macOS：
ping -D -s 1472 8.8.8.8 - Linux：
ping -M do -s 1472 -c 3 8.8.8.8
这里的 1472 是数据部分长度，加上 28 字节的 IP 与 ICMP 头部，正好是 1500。如果返回类似“需要分片但已设置禁止分片”或“消息过长”的提示，就把 1472 依次减小，比如 1452、1432、1412，直到能通过，把这个长度再加上 28，就是当前路径实际可用的 MTU。如果所在网络屏蔽 ICMP，这个方法会失效，此时可以在客户端里逐步尝试更小的 MTU 值观察效果。
测出来之后怎么调整？
如果你使用的客户端提供 MTU 选项，可以把它调到略低于实测可用值，比如实测可用 1420，就设置为 1400 左右，留一点余量。不同客户端的设置入口和取值范围不同，请以你所用软件的实际界面与说明为准。调整后再次访问那些之前卡住的大页面，能顺利加载才算验证通过。
三步都排除后，再看线路与出口
如果 DNS、IPv6、MTU 都做过检查，问题依旧，才需要把注意力放回线路本身：换一个出口再对比、观察是否总在某个时段出现。可以先记录几组数据：不同时段访问同一个页面的耗时，以及 ping 的丢包和波动。以 TonBoVPN 为例，它的一键智能路由会按平台选择线路，遇到某个平台持续不稳时，可以先让智能路由自动匹配，再对比前后的耗时记录；需要更固定的出口时，还可以选择独享 IP。以数据判断是否改善，比凭感觉反复切换节点要可靠得多。
小结
“VPN 已连接但网页打不开”并不是一个单一的问题。先按症状分诊：解析不出来看 DNS，时通时不通看 IPv6，小页面正常大页面卡住看 MTU。每一步都有对应的命令和判读方式，做完这三步再考虑线路，能省下大量盲目切换节点的时间。
延伸阅读
