怎么在网络上保护自己的隐私，尽可能少暴露真实 IP？我们上个网，确实有不少细节需要留意。
我把现有分流配置重新排查了一遍，发现：网页显示了代理 IP，只能说明这次网页访问的出口正常。 DNS 查询、浏览器的音视频连接，以及后台应用，可能走的是另一条路。
这篇以 Surge 和 Clash 两条主线展开：先看自己使用的客户端，完成电脑端设置，再按需查看手机端补充，最后统一检查浏览器和实际出口。
目标很明确：保留日常好用的分流，让应该走代理的流量按预期走代理，减少意外直连。 国内直连网站、直连 DNS 服务和代理入口仍可能看到你的公网 IP；这套设置不等于全设备匿名。
适用范围：本站维护的 Surge 配置、Clash Verge Rev 订阅扩展脚本，以及 Clash Meta for Android（CMFA）配置。
一、开始前：先把配置文件选对
先备份正在用的配置，记下当前节点和策略组选择，再更新对应机场、对应设备的文件。
- Mac / iPhone 的 Surge：使用 Surge
.conf配置。现有方案采用外置订阅，按文件说明填入自己的订阅地址。 - Windows 的 Clash Verge Rev：先导入机场订阅，再给这份订阅添加对应的
.js扩展脚本。 - 安卓 CMFA：导入对应
.yaml文件，在文件指定的节点订阅位置填写自己的地址，不使用 Windows 的 JS 脚本。
第一次接触分流，可以先看本站《机场分流配置：让 AI、影音和 Wi-Fi 通话各走其路》，了解业务组和地区组怎么选，再回来完成下面的设备设置。
还没有订阅：可查看鹿语云套餐与配套分流配置；想比较其他选择，也可以看Lite 产品介绍。已有可用订阅就继续使用，按设备匹配配置即可，不必为了本文重新购买。
已经有节点，但不知道怎么配：本站的分流配置与脚本文件定制服务可以按节点特点和设备整理文件。咨询时提供客户端名称、版本和使用需求；不要把完整订阅链接发到公开评论区。
更新“节点订阅”和更新“分流配置”是两件事。节点更新成功，不代表这次新增的 DNS、拒绝规则和客户端设置已经生效。请核对交付文件的维护日期，并在应用后检查当前运行配置。
二、Surge 设置
电脑端：Mac 按这四步设置
第 1 步：选中新版配置，重新载入
在 Surge 中选中对应机场的配置，确认订阅已经取得节点，再重新载入配置。重载可能重建连接，先结束重要上传或通话。
如果只是把文件下载到了电脑，或者只点了“更新订阅”，还需要确认 Surge 当前用的确实是这份配置。
第 2 步：打开规则模式、系统代理和增强模式
核对这三项：
- 出站模式：规则 / Rule。
- 设置为系统代理 / Set as System Proxy：开启。
- 增强模式 / Enhanced Mode：开启。
系统代理主要照顾愿意遵循它的应用，增强模式用来接管更多原始网络连接。两者一起使用，仍按分流规则决定哪些直连、哪些走代理。
第 3 步：检查实际选中的策略
打开策略组，查看 AI、海外网站和最终兜底组当前选中的出口。需要代理的业务，不要误选 DIRECT（直连）。
更新文件后，客户端可能保留之前的手动选择。不要只看文件写着“自动选择”，就以为界面里也已经选好了。需要固定地区的业务，选择对应地区；自动组可能切换节点，不代表固定 IP。
第 4 步：沿用配套保护，做一次请求检查
使用已更新的本站配置时，保留配套 DNS、TCP 53 拒绝规则及必要的局域网例外，不再叠加一份来历不明的“万能防泄漏配置”。
想自行核对，可在配置的 [General] 中搜索下面三项；已有就不要重复添加：
encrypted-dns-follow-outbound-mode = false
encrypted-dns-skip-cert-verification = false
udp-policy-not-supported-behaviour = REJECT
在配套文件已经配置加密 DNS 上游的前提下，前两项让它直连并保留证书校验；第三项表示匹配到不支持 UDP 的代理时拒绝该 UDP 请求。它不是所有断线场景的总保护开关。
最后各打开一次国内网页和需要代理的网页，在 Surge 请求记录里检查：前者按既有规则直连，后者命中预期代理组。能打开网页和出口正确，要分别确认。
手机端补充：iPhone / iPad 的 Surge
第 1 步：确认手机加载的是新版配置
打开手机 Surge，确认对应配置已同步或下载更新，选中它，使用规则模式并启动 VPN。
Mac 的 iCloud 文件已经更新，不代表手机当前运行的配置也已更新。请在手机上核对文件内容和实际策略选择。
第 2 步：核对两项接管设置
iOS 的 VPN 已包含虚拟网卡接管，不需要寻找 Mac 上的“增强模式”按钮。
在当前配置的编辑界面搜索 [General]，核对本站方案中的两项设置：
include-all-networks = true
include-cellular-services = true
两项配合扩大流量接管范围，第二项涉及可经互联网路由的蜂窝服务。开关已开，不等于 Wi-Fi Calling 已激活；运营商内部专用路径仍有系统例外。
第 3 步：检查自动暂停和模块
不要同时给某个 Wi-Fi 设置 suspend=true，它与上述全网络接管设置不兼容。如果出现 VPN 显示已连接却无法联网，先查这一项。
再看手机上启用的模块，有没有覆盖 DNS 或分流。模块优先于主配置，启用状态也不会随主配置跨设备同步；电脑正常，手机仍需单独确认。
第 4 步：分别检查 Wi-Fi 和蜂窝网络
先在日常 Wi-Fi 下打开测试网页，查看请求策略和出口；再使用自己已有的正常蜂窝网络重复检查。不需要为了测试购买漫游流量。
如果使用 Wi-Fi Calling，按对应教程另行检查运营商网关、地区节点和实际通话。暂时不用的 WFC 组保持原有拒绝保护，不要为了“让它不报错”改成 DIRECT。
三、Clash 设置
电脑端：Windows 使用 Clash Verge Rev
第 1 步：把脚本加到对应订阅
打开订阅页面 → 右键对应机场订阅 → 扩展脚本，放入该机场的新版 JS，保存并重新应用这份订阅。
不要把 JS 当作订阅链接填写，也不要把多家机场的脚本全部叠加到全局。保存后检查有无脚本报错；报错时客户端可能仍在用旧配置。
第 2 步：启用服务模式和虚拟网卡
在设置中确认服务模式已安装并运行，然后开启虚拟网卡模式（TUN），代理页面保持规则模式。
只打开“系统代理”不等于所有应用都已被接管。进入虚拟网卡的设置，核对：
- 自动设置全局路由：开启，对应
auto-route: true。 - 严格路由：开启，对应
strict-route: true。 - DNS 劫持：同时包含
any:53和tcp://any:53；单行输入框填写any:53,tcp://any:53，用英文逗号分隔。 - 协议栈、MTU：先保留当前正常值，不照抄其他电脑的参数。
严格路由有助于处理 Windows 的部分多网卡 DNS 绕行问题，但可能影响虚拟机等网络场景；它也不是退出核心后仍保证断网的独立开关。
第 3 步：避免旧覆写盖住新版配置
使用本站这套脚本、且没有必须保留的自定义 DNS 时，关闭额外的旧 DNS 覆写。已有企业内网等特殊解析需求的，先核对冲突再调整。
本方案保留应用 IPv6 开启、DNS IPv6 关闭，分别对应顶层 ipv6: true 和 dns.ipv6: false。一个关系到核心处理 IPv6，另一个限制域名的 IPv6 地址解析，不能当成同一个开关。
第 4 步：看“当前配置”，再看连接
打开设置 → Verge 高级设置 → 当前配置，核对最终生效的 DNS、TUN 和 IPv6 设置。不同版本也可能提供“查看运行时订阅”入口。
以实际生成并加载的配置为准。 Verge 会在扩展处理后回写部分界面设置，所以脚本里写了什么，不一定就是最终值。保存、重新应用后，再到连接页面确认目标业务命中正确节点。
如果严格路由开启后虚拟机断网，先记录版本和冲突设置，再处理兼容问题；不要通过关闭系统防火墙解决。
手机端补充：安卓 CMFA
第 1 步：导入安卓 YAML
在 CMFA 的配置页面从文件导入对应 YAML，按交付说明填好节点订阅地址，更新并选中这份配置，再到代理模式中选择规则模式。
不要导入 Windows 的 JS，也不要把桌面 TUN 配置整段搬到手机上。
第 2 步：停止服务后，进入“设置 → 网络”
部分网络选项在运行时不能修改。先结束重要连接，停止 CMFA 服务，再按下面核对：
- 自动路由系统流量：开启。
- DNS 劫持：开启。
- 允许应用绕过：关闭。
- 允许 IPv6：关闭，与本站安卓 YAML 的对应设置保持一致。
- 访问控制模式：选择“允许所有应用”，避免需要保护的应用被排除。
所有应用进入 VPN，不等于所有应用都走海外节点。国内业务仍可在 VPN 内按规则直连，无需为了国内访问速度排除整个应用。
第 3 步：重新启动，再打开系统断网保护
确认 CMFA 能正常连接后，进入安卓系统的 VPN 设置，找到 CMFA。系统支持时同时开启：
- 始终开启 VPN。
- 阻止不使用 VPN 的连接。
前者让系统维持 VPN 服务，后者在 VPN 不可用时阻止应用普通联网。开启后遇到服务重建或尚未连接而断网，可能正是保护在起作用。
手机厂商的菜单名称可能不同，系统蜂窝服务和热点下游设备也不一定在同一保护范围内。
第 4 步：核对“私人 DNS”和浏览器安全 DNS
先记下现有状态。若开启了自定义私人 DNS 或浏览器自定义安全 DNS，它们可能使用独立解析路径，需要另外检查。
出现结果不一致时，可在确认 CMFA 的加密 DNS 正常后，临时关闭自定义项做一次对照，检查完再按需要恢复。名称中有“私人”或“安全”，不代表它一定经过你选择的节点。
四、通用检查：电脑浏览器的 WebRTC
WebRTC 常用于网页音视频通话。即使网页请求走了代理，相关连接仍需单独检查。
这次我使用的是桌面 Edge 的 WebRTC Protect 扩展，操作如下：
- 打开扩展的选项 / Options。
- 选择 Enabled。
- 模式选择 Disable non-proxied UDP (force proxy)。
- 点击 Save Options，再打开 BrowserLeaks WebRTC 检测。
重点看 WebRTC Public IP Address 有没有出现自己的宽带或蜂窝公网 IP。仅看到 192.168.x.x 等局域网地址，与暴露公网出口不是一回事；RTCPeerConnection=True 也不等于保护失败。
保存页面工作、重启浏览器后再测一次；经常用无痕窗口的，也单独测。扩展可能受其他扩展或管理策略影响，不能只凭图标判断生效。
这一限制可能影响网页语音、视频和实时协作。需要这些功能时，把通话是否正常一起检查；桌面扩展也不能代替手机 App 的网络保护。
五、设置完，用几分钟做一次自查
① 检查出口和实际策略
打开 BrowserLeaks IP 页面，同时看客户端连接记录。确认这次访问按预期走代理，页面显示的出口与所选节点相符。
再打开国内日常网站，确认保留直连的业务正常。不要把自己明确保留的 DIRECT，和“本该代理却意外直连”混为一谈。
② 检查 DNS，但不要只看国旗
运行 DNS 检测，记录出现的解析商，再与配套配置比较。
Surge 当前方案保留直连 DoH，看到国内解析商并不自动代表设置失败；Clash 的普通业务解析与国内直连、节点引导解析分开，也可能出现不同解析商。 检测页通常展示解析服务信息，单凭国旗不能证明你的 DNS 连接是否经过代理。发现不认识的解析商，再查覆写、系统 DNS 和应用自带解析。
③ 检查 WebRTC 和 IPv6
按上一节检查 WebRTC。IPv6 则先确认当前宽带或蜂窝网络本来有没有可用公网 IPv6：没有，就记为“这次未验证”，不要记成防护通过。
如果页面显示 IPv6，先分清它是代理服务器出口还是本机宽带地址。仅关闭 DNS IPv6 查询，不代表已经阻断全部 IPv6 连接。
④ 换网或重启后，再复查
保存工作后，按日常方式切换 Wi-Fi / 蜂窝，或重启客户端，再检查上述结果。需要特别严格的断线保护时，另行测试服务退出、异常断开和恢复过程，不在远程协助或重要通话中临时尝试。
检测页适合快速筛查，不能证明所有应用、协议和故障窗口都安全。 出现异常时，记下设备、客户端版本、配置名称、时间和目标网站，比一句“DNS 泄漏了”更容易查清原因。
六、原理和实测，只记住这几个结论
DNS 加密，不等于隐藏来源。 DoH 可以保护查询传输内容，但直连的解析服务商仍能看到来源 IP。我们曾尝试 Surge 全量 DoH 代理化，期间出现连接异常，回退后恢复，因此当前保留稳定性优先的直连加密方案，不把旧测试方案当作正式设置。
配套文件补上了哪些保护？ 本次维护处理了 DNS 引用与继承检查、部分规则优先级、UDP 不支持时的拒绝路径，以及相关空组保护。Clash 中看似重复的拒绝规则有具体用途，不要随手“精简”。这些保护针对进入客户端的流量，不能代替系统接管。
实际测试结果：2026 年 11 月 7 日，当前 Mac 的鹿语云配置完成三轮 DNS 对照及追加十分钟检查。追加检查中，两个 DNSPod 入口各取得 72/72 次有效答案；物理网卡记录 4,523 个过滤后的包头，内核丢包为 0，在受控 DNS、STUN、DoT 请求中未观察到意外物理直连回退。
也保留失败记录：下午出现过解析异常，追加测试仍有代理 HTTP、DoT 失败；一组后台远程协助流量实际由 Surge 按 DIRECT 转发，对端仍能看到源 IP。不能把这些结果写成“全绿”或“零暴露”。
发布者：1taoqi，转转请注明出处：https://1taoqi.com/ip-leak/
微信扫一扫 
