IP 检测台

IPv6 会绕过代理吗？双栈网络排查方法

首页显示代理出口，另一次检测却出现了运营商的 IPv6 地址。问题可能出在另一条没有按预期处理的路径，也可能只是你比较了不同层的地址。下面以 Mihomo 为例，先分清结果，再检查接管和规则，最后把 IPv4、IPv6 分开复测。

更新于

第一步：确认你看到哪一种地址

IPv6 本身不会主动“绕过代理”。真正要查的是：你希望经过代理的连接，有没有被客户端接收，并交给预期的出口。双栈网络同时提供 IPv4 和 IPv6；其中一条走对了，不能代替另一条的验证。

先回到分流检测首页，记下国内、海外、谷歌三栏的实际地址、时间和当前模式。三栏是不同目标的一次观测，既不能把不同地址直接判为泄露，也不能把某一栏成功推广成“设备所有 IPv6 都已接管”。不清楚标签含义时，先看检测结果怎么看。

地址出现的位置，决定你能据此判断什么
看到的位置它说明什么下一步
网站返回的访问者地址这个请求到达该服务时的出口对照同一请求的客户端日志与规则
连接代理服务器的远端地址设备与代理服务器之间使用的地址族不要直接当作目标网站看到的出口
系统网卡上的 IPv6 地址接口拥有地址，不证明外网可达继续看路由和实际连接结果
WebRTC 候选地址浏览器另外收集到的网络路径信息结合候选类型单独排查

地址里有冒号，只能帮你辨认 IPv6 写法。::1 是回环地址，fe80::/10 是链路本地范围，fc00::/7 是唯一本地地址范围；它们不能直接作为公网出口泄露的证据。即使地址看起来属于公网范围，也仍需确认它是网站回报的来源，还是接口信息。

第二步：确认原网络与测试目标

先记录客户端版本、系统、当前网络、代理模式和测试程序。同一台电脑切换宽带与热点，或者浏览器与其他应用走不同代理入口，都可能改变结果。比较前后测试时，尽量保持这些条件一致，不要同时换网络、换节点又改规则。

在 Windows 的 PowerShell 中，可以先运行下面的只读命令。它只读取 IPv6 路由，不修改网络设置；其他系统应使用其自带的路由查看工具。

# 查看 IPv6 路由；分别保留客户端启动前后的输出
Get-NetRoute -AddressFamily IPv6

看目标前缀、接口和下一跳是否符合预期。::/0 表示 IPv6 默认路由，但客户端可能安装更具体的路由，因此不要只找这一行。路由表也不能单独证明应用最终用了哪个出口：应用若先连接本地代理端口，后续连接由代理程序处理。

接着确认测试目标确实提供可用的 IPv6 服务。域名的 A 记录对应 IPv4，AAAA 记录对应 IPv6；拿到 AAAA 记录仍不保证能连通。支持 Happy Eyeballs 的程序可能尝试多个地址，选用能更快建立连接的一条，所以“网页打开了”并不能说明实际使用了 IPv6。

如果原网络没有可用的 IPv6，或测试端点不支持它，把这一项记为“未验证”。不必为了填满结果而临时关闭代理访问敏感目标；可以选择你有权限、且已确认双栈支持的测试服务。基线信息不足时先补信息，不急着改系统。

第三步：分清四处 IPv6 设置

客户端界面可能把多个选项都叫“IPv6”，但它们解决的问题不同。以下字段以 Mihomo 当前文档为准，其他客户端要核对自己的实现，不能按相似名称照搬。

  • 顶层 ipv6：控制内核是否接受 IPv6 流量；开启它不等于操作系统已经把所有 IPv6 流量交给内核。
  • dns.ipv6：影响内置 DNS 的 IPv6 解析；为 false 时，对 AAAA 查询回应空结果。它不是操作系统的 IPv6 总开关。
  • TUN 的 IPv6 地址与路由：tun.inet6-address 指定虚拟接口的 IPv6 地址，生效还要求顶层 ipv6: true；地址存在与路由覆盖仍要分别检查。
  • 出站代理的 ip-version：对非 DIRECT 代理，影响 server 为域名时连接服务器所用的地址族，不能据此断言目标网站看到哪一种地址。
# 字段位置示意，不能替换完整配置，也不是一键防泄露方案
ipv6: true
dns:
  ipv6: true

这段只帮助你辨认层级，不代表现在应该把两项都改成 true。Mihomo 的 TUN IPv6 功能还会在启动时检查其他网卡的 IPv6 情况；请结合启动日志核查，不在尚未确认原因时强行跳过检查。

同样，把 dns.ipv6 关掉，也不能证明已有连接、缓存结果、直接指定 IPv6 地址或未经过该 DNS 的程序全部受控。DNS 结果与连接路径需要分别验证，解析层的详细排查见DNS 泄露排查教程。

第四步：区分未接管与规则直连

保持客户端运行，在连接面板或日志里定位刚才的测试请求。核对程序、目标、时间、匹配规则和最终策略；只看到一个相似域名不足以确认是同一次连接。若日志只记录域名，没有目标地址族，就先把地址族保留为未知。

找到请求且最终策略是 DIRECT，优先检查规则顺序、策略组实际选择和兜底策略。规则直连可能正是你的设置，并不等于 TUN 没接管。希望它走代理时，应改对应规则或选择，规则原理见规则、全局和直连模式的区别。

如果 IPv4 请求有记录，而对应的 IPv6 请求没有记录，再检查虚拟接口、IPv6 路由和排除范围，以及是否有其他 VPN 或应用自己的代理设置。没有日志也可能是日志级别、缓存或请求未真正发出，不能只凭“面板里没有”就认定已经绕过。

切到全局模式只能帮助比较已经进入客户端的连接；程序没有交进来的流量，不会因为模式名称改变就自动被接收。相反，代理服务器连接本身经过物理网卡是正常联网所需，应与目标应用的直连请求分开识别。

按原因修改，保留回退方法

  1. 接管缺失：按客户端与系统文档补齐 IPv6 支持及路由，检查不必要的排除项。修改前保存配置和路由输出，不直接删除所有物理网卡路由。
  2. 策略不符：只调整命中的规则或策略组，再用原程序建立新连接，确认它确实选择预期出口。
  3. 出口不支持：若已交给代理但 IPv6 目标连接失败，检查代理端的可达能力。失败与绕过是两回事，不能靠放行直连悄悄代替。
  4. 临时限制 IPv6：若暂时无法保证所需路径，可按设备支持的方法限制相关流量，但要记录作用范围、恢复步骤和受影响业务，不能把一个 DNS 开关当作整机限制。

每次只改一层；出现新问题就回退这次修改。长期目标是让需要代理的连接经过预期出口，同时保留你有意允许的直连，不是把每一个 IPv6 地址都视为异常。

复测时分别记录两种地址族

用原来的程序和目标重新建立连接，分别记录 IPv4、IPv6 是否实际发起、是否成功、客户端策略和服务端回报的出口。目标只支持一种地址族时，另一项继续标为未验证；超时、空结果或不再显示 IPv6，都不能直接写成“没有泄露”。

回到首页检查三条线路的分流是否仍符合你的目标，再单独做 WebRTC 检测与 DNS 检测。网页出口、浏览器候选地址和解析路径是不同观察面，一项通过不能覆盖其他项。最后重启客户端复查一次，确认配置保存后仍生效；结论限定在实际测过的网络、程序和目标上。

相关文章