目录
谷歌看的，可不只是 IP#
我们习惯拿 IP 查询结果判断地区，但谷歌显然不愿意只看这一种判断依据。网络地址、设备位置、账号里设置的住址和工作地址，以及过去的搜索和活动记录，都可能参与它的位置判断。具体用了哪些信息，还取决于账号设置、定位权限和当时可用的信号，而且所有的这些都是动态变化的。Google 的位置说明
尤其像我们这种用 Pixel、平时又离不开 Google 全家桶的人，更有一种防不胜防的感觉：出口是一回事，手机定位、账号和使用记录又是另一回事。这里最可怕的就是由于谷歌对位置的综合判断，会直接把那原本优质的出口IP直接送回国，那么这颗IP在谷歌这就算是废了。
与其斗智斗勇，不如换个思路#
前阵子我也来回折腾过，结局心态崩了。与其研究怎么让 IP 回到原来的位置，不如换个思路：或许可以在原 IP 上套一层 WARP，谷歌这部分访问全部走 WARP。
这样不是把原 IP「洗白」，也不是保证自己能指定某个国家，而是把一部分用途交给另一个出口。账号和设备定位这些因素仍然在，但至少不必每次都拿自己珍惜的那颗 IP 去和谷歌较劲。
套一层 WARP，真的能行？#
就我自己的使用体感而言，谷歌相关服务对 WARP 的包容接受程度还是不错的，算是比较宽松、有点睁只眼闭只眼的感觉。
WARP 是 Cloudflare 提供的网络连接服务，经过它的请求，会换成 Cloudflare 的 IP 对外连接。这里用的是承载访问流量的 WARP，不是单纯更换 DNS。
关键在于：WARP 不能手动选国家，它也不是跟着 Google 给原 IP 贴的地区标签走。 Cloudflare 对它的描述是：用代表接入方大致位置的 Cloudflare IP 替换原 IP。可以把它理解成围绕建立 WARP 连接的那一侧网络，提供一个新的出口，而不是根据谷歌搜索页的地区重新安排位置。Cloudflare 的说明
不过，「对应接入方的大致位置」不能理解成精确跟随服务器物理位置。运营商路由和 Cloudflare 的接入安排可能影响连接地点，目标平台也有自己的地区判断。这是一种换出口的思路，不是固定出口的承诺。WARP 的功能边界
至于共享出口会不会不好用，还是看用途。我连续用了几个月，油管会员，搜索，gemini等谷歌服务都有良好的表现，终于不用天天为IP操心了。当然，这不代表谷歌所有产品都一样，也不能保证未来一直如此。
分流之外，也要看清 WARP 的接入路径#
整个安排其实有两层：先决定哪些访问交给 WARP，再决定 WARP 本身从哪里连接出去。 前一层是用途分流，后一层才是底层网络路径，不能只做好其中一层。
就我来说在分流这一层，谷歌相关访问全部交给 WARP，其他访问继续使用各自原来的出口。
路由规则顺序尤其重要。像 Xray 是从上往下匹配，命中第一条规则就决定出站。如果前面已经有一条「某用户的所有流量都走原落地」的规则，后面的 Google → WARP 规则就算写对了，也可能没有机会生效。思路应该是：保留必要的例外，把希望优先命中的 Google 分流放在会抢先接走它的宽泛规则之前，最后再安排其他流量的去处。
到了底层路由这一层，则要确认 WARP 的连接确实从自己预期的那台机器、那个网络出去。如果 WARP 在美国中转机上运行，却希望它通过日本落地接入 Cloudflare，就要另外保证这条连接经过落地。也要避免把 WARP 自己建立连接的流量再次送回 WARP，形成绕圈。
最后验证的也应是这两件事：目标访问有没有命中 WARP，以及 WARP 的实际出口是否符合预期。DNS 能解析、服务显示已连接，都不能替代这两个检查。若 WARP 不可用，是暂停这部分访问，还是允许退回原出口，也最好提前决定，免得以为套着一层，实际又悄悄走回了老路。
具体配置就不展开了。记住「谁走 WARP、WARP 从哪里接入、前面的规则有没有把流量先接走」，比单纯往配置里加一个名字更有用。