比特浏览器通过多层检测来判断是否发生IP泄露：它会向外部服务发起回调并发出STUN请求，核对DNS解析与HTTP头（例如X-Forwarded-For），测试IPv6和本地网段的路由，比较不同路径的源IP，一旦发现不一致便记录详情并给出修复建议，用户可以查看日志并一键复现与修补。实时提醒和修复向导可选。
先说清楚什么是“IP泄露”，顺带说明为什么要在意
简单来说，IP泄露就是你以为网络请求走了一个“中间人”（代理、VPN、浏览器内的代理设置等），但实际上有些请求绕开了那个中间人，暴露了真实IP地址。嗯，说白了，表面上看你匿名了，背后却露了马脚。
常见的泄露类型（举例解释）
- WebRTC泄露：浏览器的实时通信功能会通过STUN服务器探测本地和公网IP，若未做过滤，脚本就能读到本地IP或真实外网IP。
- DNS泄露：浏览器或系统把域名解析请求直接发给本地ISP的DNS，未走加密或代理的DNS就泄露了查询来源。
- IPv6通路：很多用户只用代理或VPN的IPv4通道，IPv6请求却直接走运营商，结果漏出真实地址。
- HTTP头泄露：代理或中间件可能在请求头里附带X-Forwarded-For、Via等，误配置会把客户端IP写进去。
- 本地程序或系统级流量：浏览器做得再好，系统里的其他应用或扩展仍可能直接发包，绕开浏览器的隔离环境。
比特浏览器怎样检测IP泄露——从原理到落地步骤（用费曼法拆解）
把问题分成几块：浏览器能主动发起哪些检测？哪些外部证据能证明“泄露”发生了？检测后的判断规则是什么？下面一步步拆开说。
1）主动回调与被动比对：核心思路
核心很简单：发出请求，然后看这条请求在外面被记录成了什么样子。要是真实IP和你期望通过的代理出口不一致，那就是泄露。比特浏览器会把这一步自动化：
- 生成一个唯一token（比如随机字符串）；
- 向浏览器控制的外部检测服务器发出若干类型请求（普通HTTP、通过代理的请求、WebRTC STUN请求、DNS解析触发等）；
- 外部服务器记录每次请求的源IP、端口、协议、是否来自IPv6、以及token；
- 浏览器本地把这些返回/日志与“期望出口IP”（例如你设置的代理IP）做比对，若不一致即标记为泄露并记录细节。
2）具体技术手段（逐项解释）
- WebRTC/STUN检测：浏览器发起STUN请求，STUN的响应包含发起请求看到的源IP，能暴露本地网段或公网地址。
- 外部回调（HTTP图片/JS请求）：在页面内插入带token的图片或fetch请求，检测服务器会在日志里写下实际来源IP。
- DNS解析对照：让浏览器使用指定域名触发解析（例如随机子域名），检测服务器或专门的DNS解析器记录哪台解析器在回答请求，判断是否走了预期的DNS通道。
- IPv6探测：同时请求仅有IPv6解析的域名或用IPv6地址回调，确认是否存在未受控的IPv6直连。
- HTTP头检查：比对请求头里的X-Forwarded-For、Via、Forwarded等字段，若包含本机地址或非期望的值则为异常。
- 端口/路由行为检测：通过检测源端口模式、TTL或路由跳数，辅助判断是否经过预期中继。
3）判断规则（什么时候认定为“泄露”）
- 任何一次外部回调的源IP不等于预期出口IP（代理/VPN提供的IP）时，立即记录为“明显泄露”。
- 若WebRTC/STUN返回本地私有网段或真实公网IP，但HTTP请求显示走了代理，这表示“WebRTC泄露”。
- DNS解析结果与通过代理的解析不一致，则标为“DNS泄露”。
- 多项检测结果不一致则提高严重级别并建议立即阻断可能的路径。
实操：你可以借鉴的检测步骤（手把手，带命令/示例）
下面这些步骤既是比特浏览器内部实现思路的外显，也方便用户自己复查。别担心，按着做能看到直观结果。
步骤一：快速查看外部看到的公网IP
在终端里运行（示例命令）：
curl -s https://ifconfig.co && curl -s https://api.ipify.org?format=json
对比输出是否与你期望的代理/VPN IP一致。如果不一致，说明至少部分流量未走代理。
步骤二：WebRTC本地IP检测（浏览器内）
可以在控制台执行一个小段JS（这里是示例思路，不一定直接拷贝运行）：
// 创建RTCPeerConnection并检查localCandidates，观察候选地址是否包含本地网段或公网IP
如果能看到192.168.x.x、10.x.x.x等本地地址或本机的公网IP，说明WebRTC在暴露本地/公网信息。
步骤三：DNS泄露检测
在命令行中用dig或nslookup：
dig @1.1.1.1 example.com +short dig example.com +trace
把返回的解析器与你设定的DNS服务对照。如果解析是由ISP的DNS回答，而不是你预期的DoH/DoT或代理DNS，就可能泄露。
步骤四：检查HTTP头（是否有X-Forwarded-For等）
模拟请求并查看服务器看到的头，例如用curl带上自定义header转发到你的检测端：
curl -I -x http://你的代理:端口 https://目标域名
检查响应头或服务器端日志是否含有X-Forwarded-For字段，若其值为真实IP则说明代理链配置有问题。
一张表快速对应检测项、工具与判断依据
| 检测项 | 工具/方法 | 判断依据 |
| 公网IP | curl ifconfig.co / api.ipify | 返回IP != 期望出口IP |
| WebRTC | 浏览器控制台JS / STUN请求 | 出现本地网段或真实公网IP |
| DNS | dig/nslookup / 专用DNS检测域名 | 解析由非期望DNS回答 |
| IPv6 | ping6 / curl -6 | IPv6流量不走代理 |
| HTTP头 | curl -I / 服务器日志 | X-Forwarded-For等包含真实IP |
发现泄露后如何修复（实用清单）
- 禁用或限制WebRTC：在浏览器设置或通过策略关闭本地IP暴露（或启用“仅通过代理路由WebRTC”）。
- 强制DNS走加密通道：启用DoH/DoT或配置浏览器内部DNS到可信解析器，不让系统默认DNS回退。
- 处理IPv6：如果代理不支持IPv6，可在系统或路由器上禁用IPv6，或使用支持双栈的代理。
- 检查HTTP代理链设置：确保代理不会把客户端IP写入X-Forwarded-For，或使用匿名/无头转发。
- 限制扩展与本地应用：移除不必要扩展，检查RPA脚本是否在不经意间做了外部回调，给RPA网络权限加白名单。
- 使用系统防火墙：阻止未走代理的进程发出外部请求（设置仅允许代理进程出网）。
- 定期复测：像比特浏览器那样，把检测流程自动化，定期或在网络变化时跑一遍。
一些容易混淆的点，顺便澄清
- “浏览器显示通过代理，但仍泄露”：通常是WebRTC或DNS没走代理，或某些请求被系统层面拦截绕过浏览器代理。
- “只有个别网站看见我的真IP”：可能是该网站用第三方资源（CDN、统计脚本）直接向你的浏览器发起请求，第三方服务器记录了你的源IP。
- “日志里看到多个IP”：这可能是代理链里不同节点的IP，也可能表明存在透明代理或中间件。要逐个排查。
嗯，这样一来，你大概能理解比特浏览器检测IP泄露的主要思路：发出能证明“谁看到我的请求”的信号，然后把外部看到的和内部期望的做比较。真正有用的是把这些检测常态化，并把发现的异常变成可操作的修复步骤。若你愿意，我可以把上面的检测清单做成一键执行的脚本，或者把常见问题按情境列成快速修复按钮，方便你在不同网络环境下快速排查。