一、为什么“出口 IP”不等于“IP 环境”

配置代理或网络转发方案之后，很多人习惯先打开一个 IP 查询页面，确认当前出口地址是否已经切换。看到页面显示的 IP 已经变成目标地区，就认为网络环境已经配置完成。

但这个判断并不完整。

出口 IP 只是网络环境中最表层的信号。完整的 IP 环境涉及多个独立维度，每个维度都可能导致检测结果不一致。

常见维度包括：

• HTTP 出口 IP：当前网页请求实际使用的公网 IP。
• GeoIP 归属：GeoIP 数据库识别出的国家、地区、城市和运营商信息。
• IP 类型：Residential、Business、Datacenter / Hosting、Mobile 等类型。
• ASN 信息：Autonomous System Number，自治系统编号，用于标识 IP 段归属于哪个运营商或机构。
• DNS 出口：域名解析请求实际使用的 DNS 服务器地址。
• WebRTC 信息：浏览器通过 STUN 协议收集 ICE Candidate 时，可能暴露的本地地址或公网地址。
• IPv6 地址：如果设备启用了 IPv6，而当前转发方案未覆盖 IPv6 流量，可能出现额外的 IPv6 出口。

这些维度共同构成了一个网络节点的 IP 环境。
只看 HTTP 出口 IP，很容易忽略 DNS、WebRTC、IPv6 等路径带来的差异。

二、WebRTC 泄露的协议层原因

WebRTC，全称 Web Real-Time Communication，是浏览器中的实时通信能力，主要用于音视频通话、数据通道和点对点连接。

WebRTC 在建立连接前，需要收集 ICE Candidate，也就是候选连接地址。这个过程通常会通过 STUN 服务器完成。

STUN 的作用，是帮助客户端判断自己在 NAT 网络下的公网出口地址。

问题在于：
STUN 请求通常基于 UDP，可能不会完全遵循浏览器中配置的应用层代理规则。

因此，即使 HTTP 请求已经走了代理，WebRTC 的 STUN 探测仍然可能通过系统默认网络发出，最终暴露真实公网 IP 或本地网络地址。

常见情况如下：

• 只配置普通系统代理，未处理 WebRTC：WebRTC 可能仍然走默认网络。

• 使用浏览器代理插件，但未禁用 WebRTC：结果取决于插件是否处理 WebRTC 通道。

• 使用 TUN 模式接管系统流量：通常可以更完整地覆盖 WebRTC 相关流量。

• 在 Firefox 中关闭 media.peerconnection.enabled：WebRTC 功能被禁用，不再产生 WebRTC 候选地址泄露。

检测 WebRTC 泄露的基本逻辑是：

1. 在浏览器中调用 RTCPeerConnection API。

2. 触发 ICE Candidate 收集。

3. 读取返回的候选地址列表。

4. 将候选地址与当前 HTTP 出口 IP 进行比对。

5. 如果出现不一致的公网 IP 或异常本地地址，则说明存在需要排查的 WebRTC 暴露问题。

三、DNS 出口不一致的常见原因

DNS 请求和 HTTP 请求不一定走同一条路径。

这也是很多网络环境检测中容易出现差异的原因之一。

1. SOCKS5 没有使用远端 DNS 解析

SOCKS5 代理通常涉及两种域名解析方式：

• 本地解析：客户端先在本地 DNS 服务器解析域名，再将解析后的 IP 地址交给代理连接。

• 远端解析：客户端将域名交给代理服务器，由代理服务器在远端完成解析。

如果使用的是本地解析模式，DNS 请求并不会经过代理服务器，而是直接走本地网络中的 DNS。

这种情况下，HTTP 出口 IP 可能显示为目标地区，但 DNS 出口仍然显示为本地网络。

2. 系统 DNS 与代理 DNS 配置冲突

系统 DNS 通常由当前网络或运营商自动分配。

但代理节点所在地区与系统 DNS 所在地区可能不同。部分应用程序不会读取浏览器代理配置，而是直接使用系统 DNS。

这会导致：

• 浏览器网页请求走代理；
• 某些 DNS 请求仍然走系统默认路径；
• 检测结果中出现 HTTP 出口与 DNS 出口不一致。

3. DoH 配置独立于代理设置

DoH，即 DNS over HTTPS。

Chrome、Firefox 等浏览器都支持单独配置 DoH 服务。DoH 的配置与系统 DNS、浏览器代理插件并不完全等同。

如果 DoH 服务选择不当，可能出现：

• HTTP 出口在一个地区；
• DNS over HTTPS 请求走另一个地区；
• 检测结果显示 DNS 与 IP 不一致。

判断 DNS 是否正常，不能只看能否打开网页。更合理的方式是查看 DNS 出口的 GeoIP、ISP 和 HTTP 出口 IP 是否大致一致。

四、IPv6 泄露：独立协议栈带来的问题

IPv4 和 IPv6 是两套不同的协议栈。

在很多现代网络环境中，IPv6 会默认启用。但部分代理或网络转发方案只处理 IPv4 流量，并没有同时接管 IPv6。

如果同时满足以下条件：

• 当前网络分配了 IPv6 地址；
• 设备启用了 IPv6；
• 网络转发方案没有覆盖 IPv6 流量；

那么访问支持 IPv6 的站点时，请求可能会直接通过 ISP 分配的 IPv6 地址发出。

这会导致一种情况：

• IPv4 出口显示为代理后的地址；
• IPv6 出口仍然显示为真实网络地址；
• 检测结果中出现两个不同来源的网络出口。

处理思路通常有两类：

1. 在系统或网络层关闭 IPv6
   适合不需要 IPv6 的场景，但不适合必须使用 IPv6 的网络环境。

2. 使用能同时接管 IPv4 和 IPv6 的网络方案
   例如 TUN 模式或其他更底层的流量接管方式。

IPv6 泄露容易被忽视，是因为很多用户只关注 IPv4 检测结果，却没有检查设备是否存在额外的 IPv6 出口。

五、IP 类型识别：ASN 与数据库标签

IP 类型判断通常依赖 ASN、ISP 信息和第三方 IP 数据库。

常见 IP 类型包括：

• Residential：住宅宽带网络。
• Business：企业或商业网络。
• Datacenter / Hosting：数据中心或托管服务商网络。
• Mobile：移动网络。

不同类型的 IP，在数据库中的标记方式不同。

例如：

• ASN 归属于 Comcast、AT&T、Verizon 等运营商，通常更接近 ISP 或住宅网络。
• ASN 归属于 AWS、Google Cloud、DigitalOcean、Vultr 等云服务商，通常更接近 Hosting 或 Datacenter 类型。
• ASN 归属于移动运营商，则可能被识别为 Mobile 类型。

IP 类型并不是通过 IP 地址表面就能直接判断的，而是依赖数据库对该 IP 段、ASN、运营商和历史使用情况的综合标注。

在检测时，可以重点查看：

• ASN 编号；
• ASN 组织名称；
• ISP 名称；
• IP 类型标签；
• 是否被标记为 Hosting、Proxy、VPN、Tor、Crawler 等风险属性。

这些信息可以帮助判断当前出口更接近普通网络、商业网络，还是数据中心网络。

六、完整 IP 环境检测应该看哪些项目

完整的 IP 环境检测，至少应该覆盖以下几个维度：

HTTP 出口 IP
查看当前网页请求实际使用的公网 IP。

GeoIP 归属信息
查看国家、城市、运营商、时区等信息是否符合预期。

ASN 与 IP 类型
判断 IP 段属于运营商、企业网络、移动网络，还是数据中心网络。

DNS 出口信息
判断 DNS 请求是否与 HTTP 出口来自相近地区或同一网络环境。

WebRTC 候选地址
判断浏览器是否暴露了本地地址或额外公网地址。

IPv6 出口
判断设备是否存在未被覆盖的 IPv6 网络出口。

实际排查时，可以使用支持 IP 类型、ASN、DNS、WebRTC、IPv6 检测的工具进行交叉验证。本文示例使用 ip6个6作为结果参考，重点不在工具本身，而在于理解各项检测维度之间是否一致。

七、小结

出口 IP 只是 IP 环境中的一个指标。

真正完整的 IP 环境，应该同时包含 HTTP 出口、GeoIP 归属、ASN、IP 类型、DNS 出口、WebRTC 状态和 IPv6 状态。

如果只看出口 IP，很容易忽略 DNS、WebRTC、IPv6 等独立路径带来的信息差异。

因此，判断一个网络环境是否完整，不能只看“IP 是否已经切换”，而应该逐项确认不同网络层次的检测结果是否一致。