Chrome IP保护只遮名单内第三方请求：跨境团队的 IP 一致性自检该怎么重写

先别急着下线，这个检测页里有两个 IP

每天开号前打开一个IP检测页，看一眼出口IP没问题，才登录账号——这是很多运营团队雷打不动的动作。但如果你最近在Chrome隐身窗口里做这件事，并且登录了Google账号，可能会发现同一张页面上出现了两个不同IP：页面主体读到的IP，和某个第三方脚本读到的IP对不上。先别急着怀疑代理被劫持，这很可能是Chrome IP Protection在起作用。

先把事实说清楚：它到底遮的是谁的 IP

Chrome IP Protection（IP保护）并非一个默认对所有网站生效的全局代理。它的生效条件有四个限定：隐身模式（Incognito Mode）、已登录Google账号、目标域名在Masked Domain List（MDL）名单内、并且该请求处于第三方上下文（Third-party Context）。

只有当这四个条件同时满足，Chrome才会把请求送入双跳代理架构（Two-Hop Proxy）。第一方上下文（Top-level Domain）请求，也就是以地址栏中顶级域名为主体的请求，即使域名在名单内，也不会被遮蔽。MDL是一份动态更新的名单，官方从未公布过完整固定域名清单——所以不要把网上流传的「MDL完整列表」当真。

它不是 VPN，也不是你配置的代理

IP Protection采用双跳代理架构：第一跳由Google运营，只知道客户端IP和第二跳地址；第二跳由外部CDN运营，只知道目标域名。这样设计的目的，是让任何单一方都无法同时关联「用户IP」和「访问的域名」。它要解决的是隐私层的关联问题，而不是网络出口统一的问题。

对照一下日常使用的三层出口：

层	出口决定者	是否受IP Protection影响
宿主机网络出口	本地路由器/系统	否，第一方请求读出此层
浏览器名单式遮蔽	Google MDL + 双跳代理	是，仅限隐身+已登录+名单内第三方请求
环境级代理	指纹浏览器配置的HTTP/HTTPS/SOCKS5	否，代理层独立生效

IP Protection只作用于中间那层，而且只覆盖一小部分请求。把它当成系统级VPN或者全局代理，从一开始就走错了方向。

运营侧的真实后果：自检页读数怎么会对不上

对运营团队来说，真正的坑在于同一个页面出现两套读数。你在隐身窗口打开一个IP检测页，检测页主体属于第一方请求，读的是宿主机/网络出口IP；而页面里集成的某些第三方脚本或资源，如果恰好命中MDL，读的是双跳代理IP。于是「IP检测网站不准」这个印象就被强化了——准确说，是口径从源头就不一致。

更要命的是，平台侧观测的方式和检测页呈现的方式原本就不是一回事。平台拿到的是你登录环境发出的请求所带的IP，不是检测页显示的那个读数。所以指望用一个检测页的数字来判断「环境有没有问题」，在Chrome IP Protection出现之前就有误差，现在只是被进一步放大了。

重写自检流程：从看一个检测页到多源交叉

重写自检流程的第一步，是决定在哪个环境里自检。实际用于登录账号的浏览器环境，而不是宿主机的一个普通隐身窗口。因为IP Protection只作用于Chrome隐身模式，而你的登录操作很可能不在这个窗口里。

第二步，用两个以上不同来源的检测页交叉比对，而且要把读数拆开看：页面主域读到的IP是什么，页面内第三方资源读到的IP是什么。两个来源都一致，才说明出口稳定。

第三步，把IP归属地、时区、系统语言/Accept-Language放在一起核对。IP归属地对应时区，时区对应系统语言，三者互为印证。只看IP，等于只看到了一半环境信号。

最后，记录基线值。环境配置改过、代理线路换过之后，做一次完整记录；后续每次开号前，用差异比对而不是单次读数来判断。单次读数只能告诉你出口IP是什么，差异比对才能告诉你环境有没有异常。

在NexBrowser环境里做一致性核对

在NexBrowser环境里，这套流程可以落到具体的操作动作。每个NexBrowser环境自带独立的HTTP/HTTPS/SOCKS5代理配置，代理出口作用于该环境内的所有第一方和第三方请求，不依赖宿主机Chrome的隐身模式机制。同时，每个环境的Cookie和缓存是隔离的，不会跨环境串扰——这正好满足上面说的「在实际登录环境内自检」。

批量场景下，可以用窗口同步在多个环境里同时打开两个检测页，完成一轮一致性复检；团队需要留痕的话，用Local API把自检结果写进内部开号流程或值班记录。注意，这不代表NexBrowser内置了IP保护或有自己的IP池——它只是提供了环境级代理的配置与隔离能力，代理线路本身仍由你自行选择。多个浏览器环境同时打开检测页进行IP一致性复检的示意图