Service Worker 能拦下页面发出的请求，这一点常被理解成它能改掉代理IP 的走向。实际上它拦的是请求本身，请求最后还是要交给浏览器的网络栈发出去——代理IP 该怎么走还是怎么走。真正容易让人误判的，是它另外三个机制带来的”看起来没走代理”的假象。
Service Worker 拦的是请求，不是出口
Service Worker 是浏览器内部运行的一段脚本，注册之后可以接管作用域内页面发起的请求。它能决定的是”这个请求要不要发、能不能用本地缓存顶上、要不要改一下再发”，决定不了”这个请求从哪个地址出去”。
出口这件事由浏览器的网络栈负责，网络栈遵守的是系统或浏览器里配置的代理设置。换句话说，页面请求被 Service Worker 接管之后，最终仍然按既定的代理IP 出口转发。下面这张表把几种情况拆开看会更清楚。
| 请求类型 | 是否交给网络栈 | 与代理IP 的关系 |
|---|---|---|
| 页面主文档 | 是 | 按配置走代理IP 出口 |
| SW 脚本的注册与更新检查 | 是 | 也是真实请求，同样走代理IP |
| SW 内 fetch 后再发出的请求 | 是 | 仍由网络栈发出，出口规则不变 |
| 命中 Cache API 直接返回 | 否 | 请求根本没发出去，也就没经过代理IP |
| 不在 SW 作用域内的请求 | 是 | 按配置走代理IP 出口 |
机制一：注册与更新本身就是两次独立请求
注册请求。页面第一次调用注册方法时，浏览器要去把 Service Worker 的脚本文件取回来，这是一次实打实的网络请求，会经过代理IP 出口。脚本没取回来，注册就失败，后续谈不上接管。
更新检查。注册成功之后，浏览器会在合适的时机再去比对一次脚本内容——多数实现是字节级比对，只要有一个字节不同就认为有新版本。这意味着哪怕脚本没变，也可能多出一次请求。走代理IP 时如果出口位置频繁变动，这次比对本身可能被拉长，表现为页面首次打开要多等一小段。
skipWaiting 与 clients.claim。新版本下载完成后默认处于等待状态，要等所有旧页面关掉才接管。调用 skipWaiting 可以跳过等待立即接管，clients.claim 则让新版本立刻控制已经打开的页面。这两个开关影响的是”什么时候开始接管”，与出口无关，但会让现象在不同时间点看起来不一样。
机制二：缓存命中会制造”没走代理IP”的假象
Cache API。Service Worker 可以把响应对象完整存进自己的缓存空间，下次遇到匹配的请求就直接把存好的响应返回给页面,不经过网络。这是离线能力的基础,也是误判的主要来源。
离线命中。命中缓存时请求压根没有发出去,自然也谈不上经过哪条代理IP 链路。于是就出现了一种很迷惑的情况:明明刚换了代理IP 出口,页面内容却一点没变——不是出口没换,是这次响应压根没去找出口。
怎么分辨。打开开发者工具的网络面板,看请求条目的来源标注:命中 Service Worker 缓存的请求会标明来自缓存,响应耗时通常极短,而且没有对应的远程地址。若来源标注是网络且能看到远程地址,那这次请求确实走的是代理IP 出口。
排查出口问题时,建议先做一步隔离:临时注销 Service Worker 或者清掉该站点的数据,再重新访问一次,看到的结果才是干净的。很多人卡在”换了出口却没变化”这一步,最后发现问题出在缓存层而不是代理层。