本地网络检测与 IPv4/IPv6 双栈分流排查：从公网出口、优先协议到命令行验证

摘要

在双栈网络中，很多"莫名其妙"的现象其实来自同一个根源：IPv4 与 IPv6 走了不同的路径。浏览器的优先协议由系统地址选择规则决定，而这一规则既受运营商通告影响，也受代理与隧道配置影响。结果是同一台电脑访问同一个网站，可能一次走代理、一次直连；同一个域名解析出两个协议栈的地址，却分别归属不同运营商。本文从双栈网络的基本行为讲起，说明 IPv4 与 IPv6 为什么会分属不同网络、四种常见分流形态如何识别、如何用命令行与在线工具分别验证两个协议栈的出口，并给出代理、VPN、隧道场景下的排查与加固方法。

一、本地网络检测要回答的四个问题

"我的本机 IP 是什么"这个问题看似简单，实际包含四层信息，缺一层都可能得出错误结论：

本机公网 IPv4 出口是什么？ 这是访问大多数服务时实际使用的地址；
本机公网 IPv6 出口是什么？ 在 IPv6 可用时，它可能成为默认路径；
系统优先使用哪个协议栈？ 决定了"默认情况下会走哪条路"；
不同目标是否走了不同线路？ 例如访问境内站点与境外站点是否分属不同出口。

只报告第 1 项的工具，在双栈环境下很容易误导使用者：用户看到 IPv4 显示为代理地址，就认为环境正常，却不知道浏览器实际上优先走了 IPv6 直连。

二、双栈网络的基本行为

2.1 IPv4 与 IPv6 不是"两条网线"

一个常见的误解是把 IPv4 与 IPv6 理解为两条独立的物理链路。实际更接近的描述是：同一张网卡上同时存在两套地址栈。它们共享物理链路与路由表的一部分，但各自有独立的地址、独立的路由条目，甚至可能有独立的 DNS 配置。

这意味着：

网卡上配置了 IPv4 代理，并不会自动影响 IPv6 的路径；
运营商可能只为某一栈提供公网地址（例如 IPv4 是 CGNAT，IPv6 是真公网）；
两栈的 MTU、路由优先级可以不同。

2.2 优先协议栈是怎么决定的

系统在选择使用哪个源地址与目标地址时，遵循地址选择规则（RFC 6724 定义的默认地址选择算法）。它的核心思想是按"匹配程度"排序候选地址对，考虑因素包括：

地址的作用域（例如链路本地与全局地址的优先顺序不同）；
前缀匹配情况（目标地址是否与本地某个前缀在同一范围）；
隐私扩展地址的优先（临时地址通常优先于稳定地址）；
最长匹配与规则表顺序。

工程实践中更直观的结论是：在 IPv6 可用且目标同时具备 A 与 AAAA 记录时，IPv6 通常被优先选用。 同时，为了不因某一条栈故障而卡住连接，客户端普遍实现了 Happy Eyeballs（RFC 8305）：并行尝试两种协议，先建连成功的胜出。这就解释了为什么有些用户会觉得"IPv6 时好时坏"------两条栈都在被尝试，哪条先成功取决于当时的网络状况。

2.3 为什么同一台机器两个协议栈归属不同

这是双栈排查中最关键的一点。以下情况都会导致归属分离：

运营商 IPv6 直连未纳管：代理只配置了 IPv4，IPv6 出口直接使用运营商地址；
IPv4 为 CGNAT，IPv6 为公网：IPv4 出口显示为运营商共享池，IPv6 显示为真实前缀；
企业内网 IPv6 走独立出口：办公网 IPv4 经总部统一出口，IPv6 由本地 ISP 提供；
隧道机制：通过 Teredo、6to4 等机制获得的 IPv6，其流量实际封装在 UDP/IPv4 中，出口表现与原生 IPv6 完全不同。

在实测数据里，这种分离非常常见。例如同一台设备上，IPv4 出口的运营商与地理推断落在某个省份的城域网，而 IPv6 出口落在另一城市的前缀------两者注册国家相同、ASN 不同，属于典型的分栈差异。看到两个归属不同的地址时，先判断是不是同一条物理线路的两个栈，而不是急于判定"异常"。

2.4 MTU 与分片：双栈里的"隐形杀手"

还有一个常被忽略的差异是 MTU。IPv6 规定中间设备不得对数据包分片，路径 MTU 的发现只能依赖 ICMPv6 的 Packet Too Big 报文。如果这条 ICMPv6 被防火墙拦截，就会出现一种很典型的现象：

小请求全部正常，页面能打开，ping 也通；
一旦传输较大数据（上传文件、提交大表单、拉取大接口响应）就卡住或超时；
切到 IPv4 强制访问后问题立即消失。

这类问题在双栈排查中极具迷惑性，因为常规的连通性测试（延迟、丢包、端口可达）全部正常。判断方法是分别测试两栈下的大包传输能力，例如：

bash 复制代码

# 测试 IPv6 大包路径（注意：不同系统对 -s 的解释有差异）
ping6 -s 1400 -M do -c 3 <ipv6-target>      # Linux
ping6 -D -s 1400 -c 3 <ipv6-target>         # macOS

# 对比 IPv4 侧同样大小的包
ping -s 1400 -M do -c 3 <ipv4-target>

如果 IPv4 正常而 IPv6 在大包时失败，而小包正常，基本可以定位到路径 MTU 或 ICMPv6 被过滤。实际处置手段通常是调低隧道或接口的 MTU（例如把 1500 调整为 1480 或 1400），而不是贸然关闭 IPv6。

2.5 NAT64 与 DNS64：另一类"看起来是双栈"

部分移动网络与纯 IPv6 环境采用 NAT64/DNS64 方案：终端只有 IPv6 地址，访问 IPv4 目标时由网关做协议转换。在这种环境里：

终端侧看不到任何 IPv4 地址，但能访问 IPv4 站点；
出口表现取决于 NAT64 网关的位置与地址池；
通过合成地址（通常位于 64:ff9b::/96 等前缀）访问目标，行为与原生双栈不同。

因此，当检测结果显示"只有 IPv6 出口、但 IPv4 站点也能访问"时，不应简单判定为"IPv4 不可用"，而要考虑 NAT64 的存在。判断线索包括：本机是否存在合成前缀的地址、解析出的 AAAA 记录是否落在 NAT64 前缀内。

三、四种常见分流形态与识别方法

形态	IPv4 表现	IPv6 表现	识别要点
单一栈代理	走代理	直连本地运营商	两栈 ASN 不同，仅 v4 被纳管
双栈统一	走代理	走代理	两栈归属一致，最理想
优先栈切换	视情况	优先使用	同一域名多次访问出口可能不同
隧道式 IPv6	原生	隧道出口	需要检查是否存在 Teredo/6to4 接口

第三行值得特别说明：如果系统优先 IPv6，而 IPv6 走的是本地直连，那么用户主观上"配了代理"的印象与实际行为并不一致。此时浏览器的 HTTP 出口检测可能仍显示代理地址（因为代理配置在 IPv4 上生效，而某些工具强制走 IPv4），但实际访问业务站点时走的是 IPv6 直连。"检测显示正常"和"业务实际走哪条路"完全可能不是一回事，这也是双栈环境最容易被忽略的坑。

四、命令行验证方法

双栈排查最可靠的手段是分别强制指定协议栈：

bash 复制代码

# 分别获取两个协议栈的出口，避免被"优先协议"掩盖
curl -4 -s --max-time 8 https://api.dnspup.com/ip/4
curl -6 -s --max-time 8 https://api.dnspup.com/ip/6

# 获取系统/浏览器优先使用的协议栈出口
curl -s --max-time 8 https://api.dnspup.com/ip

# 查看本机地址与其作用域（含临时地址与隧道地址）
ifconfig | grep inet6            # macOS / BSD
ip -6 addr show                  # Linux

# 查看 IPv6 路由与默认网关来源
netstat -rn -f inet6 | head      # macOS
ip -6 route show default         # Linux

# 检查是否存在隧道接口（如 Teredo、gif、sit）
ifconfig | grep -E "^(gif|stf|utun)" ; ip -6 tunnel show

4.1 结果解读的三个要点

要点一：看 -4 与 -6 是否都能成功。 如果 -6 直接失败，说明当前没有可用的 IPv6 通道，此时"优先协议"的讨论没有意义；如果 -6 成功且地址与 -4 归属不同，就需要按第 2.3 节的四种情况逐一对照。

要点二：注意 inet6 里是否存在 temporary 标记。 隐私扩展生成的临时地址会定期轮换，这会让"出口 IP 变化"看起来像是配置问题，实际属于设计行为。

要点三：核对是否存在隧道接口。 如果发现隧道类接口，应确认它是业务需要的，还是残留配置。隧道式 IPv6 常常绕过常规代理，是排障中最容易被遗漏的一类路径。

4.2 与在线检测互相印证

命令行视角与浏览器视角必须分别采集。命令行默认不走浏览器代理，因此它反映的是系统层面的真实路径；浏览器则可能因为扩展、策略或 DoH 而走另一条路。把两组结果并列，就能快速定位差异发生在哪一层。

DNSPup 的本地网络检测页面（https://dnspup.com/localhost/ ）会把本机 IPv4、本机 IPv6、各自的地理推断、当前是否 IPv6 优先，以及不同线路的访问出口并列展示，并直接给出对应的命令行查询方式（https://api.dnspup.com/ip/4、/ip/6、/ip）。它还提供"线路分流"视角，分别观察访问普通站点、特殊站点与 WebRTC 时的出口，以及 IPv4/IPv6 泄露项------对于双栈环境来说，这种把"系统视角"和"浏览器视角"分开呈现的方式，比单一 IP 展示更接近真实情况。

五、代理与 VPN 对双栈的不同影响

5.1 浏览器扩展类代理

这类代理通常只处理浏览器发出的 HTTP(S) 请求，对系统其他流量与 UDP 完全不可见。因此在双栈环境下，最典型的结果是：浏览器 IPv4 走代理，浏览器 IPv6 可能仍走本地直连（取决于扩展是否支持 AAAA 请求的转发），而系统层面的 IPv4 与 IPv6 都不受代理影响。

5.2 系统级代理

系统代理覆盖范围更广，但同样常见"只配置了 IPv4"的情况。此外，部分代理客户端对 IPv6 的处理是直接阻断（避免泄露），这会让 IPv6 业务不可用；另一部分则透明转发，此时两栈归属可能一致。

5.3 VPN 类通道

VPN 通常按路由表接管流量，理论上可以同时覆盖两栈。但实践中仍有两个常见缺口：一是 VPN 客户端未下发 IPv6 路由，导致 IPv6 直连绕过隧道（这是 VPN 泄露检测的经典场景）；二是 IPv6 被禁用但系统未刷新，出现"部分应用仍尝试 IPv6"的中间状态。

5.4 移动网络与热点共享

移动网络的 IPv6 部署率通常高于固定宽带，因此"换到手机热点就出现异常"是很常见的一类反馈。原因在于：

移动网络往往同时下发 IPv4（多为 CGNAT）与 IPv6（原生公网前缀）；
部分机型的 IPv6 前缀会随基站切换而变化，表现为出口地址频繁变动；
通过热点共享时，下游设备的 IPv6 前缀由上游分配，链路特性与直连不同。

这类环境的关键在于区分"地址变化"与"路径变化"：前者属正常行为，后者才需要处理。判断方法是看变化是否同时发生在 ASN 层面------如果 ASN 不变而地址变，通常是地址池或多前缀分配；如果 ASN 也变了，就要考虑路径切换。

六、本地地址暴露与内网拓扑

双栈环境还会放大本地地址暴露面：IPv4 侧有局域网地址，IPv6 侧还有链路本地地址（fe80::/10）与可能的临时地址。通过 WebRTC 的 ICE 候选收集，这些地址在部分浏览器上原本是可读的。

现代浏览器普遍启用了 mDNS 混淆，把局域网地址替换为 <uuid>.local 形式的主机名，从而隐藏具体的局域网 IP。但需要注意两点：

该机制主要保护主机候选（host），不改变公网反射候选（srflx）的暴露；
不同内核的默认行为与可配置项不同，结论必须标注浏览器与版本。

因此，评估"本地网络检测"结果时，应当把"内网地址暴露"和"公网出口暴露"当作两个独立问题：前者关系内网拓扑信息，后者关系出口归属。二者需要不同的处置手段。

七、典型业务影响

7.1 一个完整的排障过程

把这些零散的知识串起来，看一个具有代表性的案例。某团队反映"同一台电脑，有时能正常访问业务站点，有时会提示环境异常"。他们的第一反应是代理节点不稳定，于是更换了多个节点，症状依旧。

第一步，分别测两栈出口。结果明确：IPv4 出口是代理节点的地址，IPv6 出口是办公线路的运营商地址------两栈完全不同。

第二步，确认优先协议。用 /ip 接口测试显示当前优先使用 IPv6。这说明浏览器在具备 AAAA 记录的情况下会优先走 IPv6，也就是走了完全没有被代理覆盖的那条路。所谓的"时好时坏"，实际取决于目标站点是否有 AAAA 记录、以及当时 IPv4 路径是否更快（Happy Eyeballs 的胜负）------业务站点有 IPv6 时走直连，没有时走代理，于是表现随机。

第三步，检查纳管范围。发现代理客户端确实只配置了 IPv4 通道，IPv6 未被接管，也没有做阻断。同时系统上还残留着一个早前安装的虚拟网卡，提供了额外的 IPv6 路由。

第四步，处置与复测。给出两个可选方案：一是让代理接管 IPv6（或在代理客户端中显式阻断 IPv6 出站），二是清理残留虚拟网卡并确认 IPv6 路由来源唯一。实施第一种方案后复测，两栈出口归属一致，业务侧异常消失。

这个案例的价值在于暴露了一个通用误区：把"随机性问题"直接归因为"节点质量"，而没有先确认"实际走的是哪条链路"。 如果一开始就分别测两栈，"问题只在 IPv6 上"这个结论在十分钟内就能得到，后续所有猜测都可以省掉。

访问稳定性。 Happy Eyeballs 会让客户端并行尝试两栈，若其中一栈质量差（例如 IPv6 路由绕行或丢包），表现为"页面时快时慢"。这类问题用单栈工具很难复现，需要在两个协议栈上分别做延迟与丢包测试。

地域一致性。 对需要地域稳定的业务，如果 IPv6 直连绕过代理，那么业务侧看到的出口归属可能时而为代理地区、时而为本地。同一账号在不同时刻呈现不同归属，是风控模型最敏感的模式之一。

解析与调度。 双栈站点的解析结果由调度系统决定，IPv4 与 IPv6 可能被调度到不同接入点。因此"解析结果不同"本身不是异常；真正需要关注的是实际建连使用的协议栈是否与预期一致。

排查误导。 最常见的代价是排查方向被带偏：团队反复调整代理节点，却始终没有意识到问题在 IPv6 直连上。一次完整的两栈出口检测通常只需几分钟，却能省掉数小时的无效调优。

八、推荐的排查流程

确认能力 ：分别执行 curl -4 与 curl -6，确认两栈是否都可用；
记录基线：保存两栈出口地址、ASN、运营商与地理推断；
确认优先栈 ：通过 /ip 接口与浏览器实际行为确认默认走哪条路；
核对归属：比较两栈是否同一物理线路（同 ASN / 同运营商）；
检查纳管范围：确认代理或 VPN 是否覆盖了两栈，以及是否覆盖 UDP 与 DNS；
清理残留：检查隧道接口、旧代理配置与双重代理叠加；
复测归档：修改后重复第 1 至第 6 步，并把结果与修改前对比。

第 6 步容易被跳过。多层代理叠加（系统代理 + 浏览器扩展 + VPN）在双栈环境下会产生难以预测的组合结果，先做减法再谈优化，往往更高效。

九、加固建议

9.1 双栈排查中的常见误区

在给出具体手段之前，先把几个反复出现的错误认识列清楚，避免在错误方向上投入时间：

"IPv4 正常就等于网络正常"：双栈环境下两栈是独立路径，IPv4 正常完全可能掩盖 IPv6 的问题。
"看到两个地址就是泄露"：同一条线路的两个协议栈本就会产生两个地址，要先核对归属再下判断。
"地址变了就是配置被改"：隐私扩展、CGNAT 池轮换、移动网络前缀更新都会造成地址变化。
"关掉 IPv6 就万事大吉"：关闭确实能消除分栈问题，但同时失去 IPv6 能力，长期看并非最优解，应先做影响评估。
"浏览器能打开就没问题"：页面对协议栈不敏感，而业务侧的风控与调度可能对路径非常敏感。
"只测一次就够"：Happy Eyeballs 会让结果随时序变化，单次测量不足以描述行为。

第 4 条尤其需要斟酌。在很多真实案例中，正确的做法不是关闭 IPv6，而是让代理或 VPN 正确接管 IPv6；只有在 IPv6 确实没有业务价值时，关闭才是合理的简化手段。

9.2 选择检测工具时的评估要点

面对各类在线检测工具，可以用下面几个问题快速评估其适用性：

是否分别展示 IPv4 与 IPv6 出口，而不是只给一个地址？
是否说明当前的优先协议栈，以及该结论是如何得出的？
是否把系统视角与浏览器视角分开呈现？
是否提供命令行接口，便于与在线结果互相印证？
是否标注字段的数据来源与更新时间？
对不确定项是否如实写成"未获取""不可用"，而不是用默认值填充？

最后一条是区分工具成熟度的关键。诚实地显示"未获取"，比用一个看似合理的默认值掩盖真实状态要有价值得多，因为排查决策正是建立在这些状态之上的。

明确目标再选择手段。 如果目标是"出口归属一致"，那么需要同时纳管两栈；如果目标是"时延优先"，则应把本地线路本身调整为合适的接入点，而不是叠加只覆盖单栈的代理。

优先使用系统级、双栈感知的通道。 系统级 VPN 通常比浏览器扩展更容易覆盖完整路径，但仍需确认 IPv6 路由是否被正确接管。

抑制不必要的 IPv6 暴露。 在不依赖 IPv6 的环境中，可以考虑关闭 IPv6 栈或明确阻断其出站，从而消除"IPv6 直连绕过代理"这一类问题。代价是无法使用 IPv6 相关能力，需要与业务需求权衡。

保持记录。 双栈环境的配置项多、变化频繁，没有连续记录就很难判断某次问题是配置变更导致还是外部网络变化导致。建议把两栈出口与优先协议一并写入例行检测日志。

十、结论

IPv4/IPv6 双栈带来的复杂性，本质上来自"一条网卡、两套地址栈、两套可能不同的路径"。要把它排查清楚，需要把四个问题分别回答：两栈各自的出口是什么、系统默认优先哪一栈、不同目标是否走了不同线路、代理与 VPN 实际覆盖了哪些路径。

据此可以总结出三条实践原则：

永远分别测试两栈，不要用一次查询代替双栈验证；
区分"归属不同"与"路径异常"，同一条物理线路的两个协议栈归属不同属于正常现象；
把系统视角与浏览器视角分开记录，两者不一致往往正是问题所在的线索。

双栈排查的技术门槛并不高，难的是形成固定的检查习惯。当"分别看两栈、分别看系统与浏览器、分别看出口与解析"成为默认动作时，那些看似偶发的访问异常就会呈现出清晰的因果关系。