全方位 IP / DNS / WebRTC / IPv6
泄漏排查与修复

连上了代理、选好了节点、延迟也正常——但你的 IP 真的"切过去"了吗？很多用户在使用代理工具时，只关注能不能连上，却忽略了一个更关键的问题：真实 IP 有没有泄漏。

泄漏的渠道比你想象的多。IP 地址只是最直观的一层，DNS 请求、WebRTC 协议、IPv6 流量——任何一个环节没处理好，都可能在你以为"安全了"的时候暴露真实位置。这篇文章的目的很具体：逐项排查每一个泄漏点，并给出对应的修复方案。

一、泄漏的本质：你以为切了，其实没切

代理工具的核心工作是把你的网络流量"转发"到远程节点，让目标网站看到的是节点的 IP 而非你的。但在流量转发的过程中，有几个环节可能"绕过"代理隧道，直接暴露你的真实信息：

这四种泄漏不是"理论风险"——在实际使用中非常常见。尤其 DNS 泄漏，几乎是新手最容易踩的坑：你以为走了代理，但 DNS 查询还是在本地运营商的 DNS 服务器上完成的，你的浏览记录对运营商来说一览无余。

二、IP 泄漏排查与修复

IP 泄漏是最直观的泄漏类型。排查方法也很简单：对比你连接代理前后的出口 IP。

2.1 排查方法

1. 先不连代理，访问 ip.sb 或 ipinfo.io，记录你的真实 IP。
2. 连接代理，再次访问同一网站，确认显示的 IP 已变为节点 IP。
3. 切换节点后重复测试，确认每次切换 IP 都正确变化。
4. 访问 ipleak.net，该网站会同时检测 IP、DNS、WebRTC，一站式排查。

2.2 常见泄漏原因与修复

原因一：代理未开启全局模式

很多客户端默认使用"规则模式"（Rule Mode），只对被墙的域名走代理，其他流量直连。如果规则没覆盖你要保护的网站，IP 就会泄漏。

• 修复：将客户端切换到"全局模式"（Global Mode）测试。如果全局模式下 IP 正常，说明问题出在分流规则上。
• 进阶：在规则模式下，手动添加你关心的域名到代理规则中（如 MATCH,你的域名,节点选择）。

原因二：客户端未接管系统流量

某些客户端（如 V2RayN）需要手动开启"系统代理"或"虚拟网卡"模式。如果只是启动了核心但没有接管系统流量，浏览器可能还是走的直连。

• Windows：确认 V2RayN 右下角托盘图标显示"系统代理已开启"（而非"仅代理"或"手动配置"）。
• macOS：在系统偏好设置 → 网络 → 代理中确认 SOCKS/HTTP 代理已指向客户端端口。

原因三：某些应用绕过系统代理

部分应用（如 Telegram Desktop、某些游戏客户端）不走系统代理，需要在应用内单独配置 SOCKS5 代理地址。或者使用 TUN 模式（虚拟网卡）强制接管所有流量。

三、DNS 泄漏排查与修复

DNS 泄漏是最隐蔽、也最容易被忽略的泄漏类型。它不会让你的 IP 暴露，但会暴露你访问了哪些网站——对运营商或网络中间人来说，你的浏览行为一览无余。

3.1 什么是 DNS 泄漏

正常情况下，当你通过代理访问 example.com 时，DNS 解析应该在代理节点上完成。但如果 DNS 请求"泄漏"到了本地运营商的 DNS 服务器，运营商就能看到你解析了哪些域名。

典型场景：你在客户端中配置了代理，浏览器通过代理访问网站，但操作系统的 DNS 设置还是指向路由器或运营商的 DNS 服务器。某些应用或系统组件直接查询本地 DNS，绕过了代理隧道。

3.2 排查方法

1. 访问 dnsleaktest.com，点击 "Extended Test"，观察返回的 DNS 服务器列表。
2. 如果返回的 DNS 服务器全部位于你的节点所在国家/地区，说明 DNS 没有泄漏。
3. 如果返回的 DNS 服务器中出现了你本地运营商的服务器（如中国电信、联通的 DNS），说明存在泄漏。

3.3 修复方案

方案一：客户端内置 DNS（推荐）

大多数现代客户端都内置了 DNS 转发功能，确保 DNS 请求走代理隧道：

• Clash / Clash Verge：在配置中设置 dns: 部分，启用 enhanced-mode: fake-ip 或 real-ip 模式。fake-ip 模式会为每个域名分配一个虚假 IP，DNS 解析在客户端本地完成，所有请求通过代理发出。
• V2RayN：在设置中开启"启用本地 DNS"和"防止 DNS 泄漏"选项。
• Sing-box：在入站配置中设置 dns 服务，将 DNS 查询路由到远程节点。

方案二：系统级 DNS 切换

如果客户端不支持内置 DNS，可以通过修改系统 DNS 来防止泄漏：

# Windows — 设置 DNS 为 Cloudflare DoH
# 在网络适配器设置中手动配置 DNS：
首选 DNS: 1.1.1.1
备用 DNS: 1.0.0.1

# 或使用 DNS over HTTPS (DoH)
# Chrome: 设置 → 隐私和安全 → 安全 → 使用安全 DNS → 自定义
# 填入: https://cloudflare-dns.com/dns-query

方案三：DoH / DoT 加密 DNS

传统 DNS 使用明文 UDP 传输，即使不泄漏到运营商，中间人也能嗅探。DNS over HTTPS (DoH) 和 DNS over TLS (DoT) 可以加密 DNS 查询：

推荐的 DoH 服务：

• Cloudflare：https://1.1.1.1/dns-query（速度快，全球节点多）
• Google：https://dns.google/dns-query（稳定可靠）
• 阿里 DoH：https://dns.alidns.com/dns-query（国内访问快）

四、WebRTC 泄漏排查与修复

WebRTC（Web Real-Time Communication）是浏览器内置的实时通信协议，支持网页音视频通话、P2P 文件传输等功能。但它的实现机制会在建立连接时向 STUN 服务器发送请求，这个请求可能绕过代理直连，暴露你的真实 IP（包括局域网 IP）。

4.1 泄漏原理

WebRTC 在进行 NAT 穿透时，会向 STUN 服务器发送 UDP 请求以获取你的公网 IP。这个 UDP 请求默认走系统路由，不会经过代理的 TCP 隧道。即使你的 HTTP 流量走了代理，WebRTC 的 STUN 请求仍然可能直连。

4.2 排查方法

1. 连接代理后访问 ipleak.net，页面会自动检测 WebRTC 是否泄漏。
2. 或者访问 browserleaks.com/webrtc，查看 WebRTC 检测结果。
3. 如果检测结果显示了你的本地 IP 或公网 IP（而非节点 IP），说明存在 WebRTC 泄漏。

4.3 修复方案

方案一：浏览器禁用 WebRTC（最简单）

• Chrome：安装扩展 WebRTC Leak Prevent 或 WebRTC Control，一键禁用 WebRTC 的非代理连接。
• Firefox：在地址栏输入 about:config，搜索 media.peerconnection.enabled，设为 false。
• Edge：与 Chrome 类似，安装对应扩展或通过 edge://flags 禁用。

方案二：客户端 TUN 模式（根治方案）

TUN 模式（虚拟网卡）会在系统层面接管所有网络流量，包括 WebRTC 的 UDP 请求。开启 TUN 后，WebRTC 的 STUN 请求也会走代理隧道，从根本上杜绝泄漏。

• Clash Verge / Nyanpasu：在设置中开启 "TUN 模式"。
• Sing-box：在配置中添加 TUN 入站。
• V2RayN：使用 "虚拟网卡" 模式（需安装 sing-box 内核）。

五、IPv6 泄漏排查与修复

随着 IPv6 的普及，越来越多的网络环境同时支持 IPv4 和 IPv6（双栈环境）。但大多数代理工具和节点只处理 IPv4 流量，IPv6 流量可能直接从你的网卡发出，绕过代理隧道。

5.1 泄漏原理

在双栈网络中，操作系统会优先尝试 IPv6 连接。如果目标网站支持 IPv6（现在大多数主流网站都支持），你的浏览器可能会直接通过 IPv6 发起连接，完全绕过代理。此时你在 IPv4 层面一切正常，但 IPv6 层面已经暴露了真实地址。

5.2 排查方法

1. 连接代理后访问 test-ipv6.com。
2. 如果页面显示你有 IPv6 地址，且该地址与你的真实 IPv6 一致（而非节点的 IPv6），说明存在泄漏。
3. 也可以访问 ipv6.icanhazip.com，查看返回的 IPv6 地址。

5.3 修复方案

方案一：禁用 IPv6（最直接）

如果你的代理节点不支持 IPv6，最稳妥的做法是在系统层面禁用 IPv6：

# Windows — 禁用 IPv6
# 方法一：注册表
reg add "HKLM\SYSTEM\CurrentControlSet\Services\Tcpip6\Parameters" /v DisabledComponents /t REG_DWORD /d 255 /f

# 方法二：网络适配器设置
# 控制面板 → 网络和共享中心 → 更改适配器设置
# 右键你的网络适配器 → 属性 → 取消勾选 "Internet 协议版本 6 (TCP/IPv6)"

# Linux — 禁用 IPv6
sysctl -w net.ipv6.conf.all.disable_ipv6=1
sysctl -w net.ipv6.conf.default.disable_ipv6=1
# 持久化：
echo "net.ipv6.conf.all.disable_ipv6=1" >> /etc/sysctl.conf
echo "net.ipv6.conf.default.disable_ipv6=1" >> /etc/sysctl.conf

方案二：客户端拦截 IPv6 流量

部分客户端支持 IPv6 拦截功能：

• Clash：在配置中设置 ipv6: false，阻止 IPv6 流量通过。
• Sing-box：在出站配置中明确指定 ip_version: ipv4。

方案三：防火墙规则拦截

使用防火墙规则阻止非代理的 IPv6 连接：

# Linux — nftables 拦截 IPv6 出站（保留本地通信）
ip6tables -A OUTPUT -d ::/128 -j ACCEPT          # 本地回环
ip6tables -A OUTPUT -d fe80::/10 -j ACCEPT        # 链路本地
ip6tables -A OUTPUT -j DROP                        # 丢弃其他 IPv6 出站

六、综合排查清单

完成以下步骤，确认你的代理环境不存在泄漏：

七、常见问题排查

7.1 清除 DNS 缓存

# Windows
ipconfig /flushdns

# macOS
sudo dscacheutil -flushcache; sudo killall -HUP mDNSResponder

# Linux (systemd-resolved)
sudo systemd-resolve --flush-caches

7.2 验证 TUN 模式是否生效

开启 TUN 模式后，可以通过以下方式验证：

• 在命令行执行 curl ip.sb，确认返回节点 IP。
• 访问 ipleak.net，确认所有检测项均无泄漏。
• 在浏览器中打开一个支持 WebRTC 的网页，确认 WebRTC 检测无泄漏。

八、各客户端防护配置速查