Shadowsocks 防止 IP 泄露实战：配置、检测与修复要点

• 为何连接看似通过代理却仍然泄露真实 IP
• 泄露的常见类型与成因
• 1. DNS 泄露
• 2. IPv6 泄露
• 3. UDP / 非 TCP 流量
• 4. 应用级直连（分应用代理失败）
• 5. 浏览器特有泄露（WebRTC 等）
• 检测方法：如何确认是否发生了泄露
• 第一步：表面检查
• 第二步：DNS 漏洞测试
• 第三步：协议与流量抓包
• 第四步：应用/浏览器行为监测
• 修复要点：按类型逐一堵漏
• DNS 泄露的修复
• IPv6 泄露的修复
• UDP/非 TCP 流量的修复
• 应用直连与系统路由的修复
• 浏览器泄露的修复
• 实战配置建议与优先级
• 常见误区与经验提醒
• 工具清单（检测与加固常用）
• 最后的建议

为何连接看似通过代理却仍然泄露真实 IP

很多以为只要客户端连接上 Shadowsocks 就万事大吉，事实上“成功建立隧道”只是第一步。IP 泄露通常发生在代理范围之外的流量、DNS 查询、IPv6 路由或应用层直连。要彻底防止泄露，需要从传输层、DNS、系统路由和浏览器行为几方面逐一排查并修复。

泄露的常见类型与成因

1. DNS 泄露

客户端把域名解析请求发到本地或 ISP 的 DNS，而不是通过代理转发到上游 DNS。很多系统默认使用操作系统或路由器配置，只有在将 DNS 请求强制走隧道后才能避免。

2. IPv6 泄露

Shadowsocks 很多实现只处理 IPv4，不会自动拦截或转发 IPv6 流量。若公网启用了 IPv6，终端可能通过 IPv6 直连，导致真实地址暴露。

3. UDP / 非 TCP 流量

Shadowsocks 的一些客户端或服务端对 UDP 支持不充分；游戏、VoIP、QUIC 等使用 UDP 的应用，若未通过代理转发，就会直接联网。

4. 应用级直连（分应用代理失败）

许多应用（尤其是系统服务、更新程序、某些浏览器插件）不会遵循系统代理设置，造成直连。移动端和桌面平台的行为各异，需要针对性防护。

5. 浏览器特有泄露（WebRTC 等）

浏览器的 P2P/实时通讯功能可能绕过代理直接进行候选地址收集，公开本机局域网或公网地址。

检测方法：如何确认是否发生了泄露

第一步：表面检查

访问显示公网 IP 的网站（多家比对），确认是否与代理节点一致。若不一致，说明存在直连。

第二步：DNS 漏洞测试

使用专门的 DNS 泄露测试网站，或者比较通过代理访问与不通过代理访问返回的 DNS 服务器信息，确认 DNS 查询是否走了代理。

第三步：协议与流量抓包

在客户端或本地网关上用抓包工具（tcpdump/wireshark）观察UDP和DNS报文源目标。重点关注 53 端口的流量、IPv6 数据包以及非代理端口的出站连接。

第四步：应用/浏览器行为监测

检查浏览器的 WebRTC 本地候选列表或使用隐私测试页面，确认是否有本机地址被泄露。查看应用日志，确认是否有直连记录。

修复要点：按类型逐一堵漏

DNS 泄露的修复

– 强制把系统/应用的 DNS 请求走代理：使用支持远程 DNS 的 Shadowsocks 客户端或搭配 Tun 模式，将 DNS 转发到代理侧。
– 在本地 DNS 配置中禁用 ISP DNS 或透明代理（路由器层面），将 DNS 指向可信的远端解析器或代理侧解析器。
– 对于无法直接控制的系统，使用本地 DNS 拦截（DNS 代理）并把其输出引导到隧道。

IPv6 泄露的修复

– 若服务器/客户端未配置 IPv6，建议在客户端或路由器层面禁用 IPv6（临时且有效）。
– 更稳妥的方案是配置隧道/代理同样支持 IPv6 或在防火墙中阻断 IPv6 出站流量，直到完整支持为止。

UDP/非 TCP 流量的修复

– 启用并正确配置 Shadowsocks 的 UDP 转发（若服务端支持）。
– 对必须使用 UDP 的应用，优先走基于 TUN 的全局代理（tun2socks 类方案）或把 UDP 端口重定向到本地代理进程。
– 若服务端不支持 UDP，可在客户端启用流量分流，把 UDP 流量通过远端 VPN 隧道转发。

应用直连与系统路由的修复

– 使用 TUN/TAP（系统级虚拟网卡）方式实现全局路由，确保所有进程都走隧道。
– 对于分应用代理，明确列出白名单/黑名单，并结合防火墙规则禁止未通过代理的出站连接。
– 在移动设备上注意系统更新、应用市场等可能绕过代理的服务，使用系统层流量管理或网关策略进行约束。

浏览器泄露的修复

– 禁用 WebRTC 的非必要功能或在浏览器设置中强制使用代理/禁用候选地址采集。
– 在浏览器内安装隐私扩展或使用带有内置代理/隔离模式的浏览器，降低浏览器层面的候选地址暴露。

实战配置建议与优先级

若追求高可靠性，建议按照下面优先级实施：

1) 在客户端启用系统级 TUN 模式，确保所有流量通过虚拟网卡。
2) 配置远端或客户端 DNS 代理并验证 DNS 请求路径。
3) 禁用 IPv6 或确保 IPv6 流量也被隧道覆盖。
4) 在本地或边界路由器上部署防火墙规则（iptables/nftables/pf），实现“非代理即阻断”的 killswitch 策略。
5) 针对特定应用进行额外检测（浏览器、即时通讯、系统服务）。

常见误区与经验提醒

误区1：“只要连上代理就不会泄露。” 实际上需要确保每一种流量路径都被覆盖。
误区2：“关闭代理时不会泄露。” 关闭客户端或断线时若没有 killswitch，系统通常会回退到直连。
误区3：“IPv6 很少用可以忽略。” IPv6 直接暴露的风险高，特别是在 ISP 开启 IPv6 的网络环境下。

工具清单（检测与加固常用）

检测类：公网 IP 查询网站、多家 DNS 泄露测试站、WebRTC 测试页面、tcpdump/wireshark。
加固类：支持 TUN 模式的 Shadowsocks 客户端、tun2socks、系统防火墙（iptables/nftables/pf）、DNS 代理（本地或远端）。

最后的建议

防止 IP 泄露不是一次性工作，而是一个流程：检测→确认泄露类型→针对性修复→再次验证。把 DNS、IPv6、UDP 和应用行为都纳入检查列表，优先实现系统级“所有不在隧道的出站流量直接阻断”的策略，能大幅降低意外泄露的风险。