代理和浏览器有三种集成形态：全局代理、环境级绑定和插件级代理。对比各自的作用范围、优缺点，以及认证弹窗、SOCKS 协议等常见踩坑。
代理配到浏览器上，常见的做法有三种。表面差别是操作步骤，实际差别是作用范围：谁走这个出口、改一次影响多少账号，先想清楚这一层，后面能省很多排查时间。
全局代理：一次设置，整个浏览器都走
在系统或浏览器的网络设置里挂一个出口，之后打开的所有页面、扩展发出的请求、后台的接口调用基本都会经过它。配置最快，不用逐个环境去填，特别适合单账号运营或者本地测试。
问题也在这一层。所有账号共用一个出口，等于把不同身份绑在同一条线上，只要平台按网络维度做关联判断，就会把它们看成同一批。反过来，出口抖动或掉了，也不是一个账号受影响，而是全部一起出问题。所以全局代理更适合一个人、一两个账号的场景，账号一多就开始碍事。
环境级绑定：一个环境一个出口
把代理地址和凭据填进单个浏览器环境的配置里，出口跟着环境走。打开哪个环境，就用哪个出口，账号和 IP 是固定对应的关系，换环境就换身份，彼此不干扰。
这种形态的好处是关系清晰。账号数量上来之后，环境列表本身就成了台账，谁配了哪个地区一眼能看出来，批量调整也比逐个开浏览器改设置靠谱。
用的时候有两点容易忽略。一是切换出口就不是原来的账号了：同一个环境里 Cookie 和登录态还在，IP 却换到了另一个地区，平台那边看到的就是身份和时间线全对不上，触发验证甚至限制都很正常，所以已经跑起来的账号不要随手换出口。二是复制或克隆环境时注意别把出口一起带过去，否则两个环境共用同一个 IP，隔离等于白做。
插件级代理：粒度最细，覆盖也最窄
第三种是让浏览器扩展接手代理，可以按域名、标签页或规则转发，不同站点走不同出口，切换起来也快。做跨地区比价、多站点测试这类事很方便。
它的边界要认清楚。扩展只能管到浏览器内部它自己支持的请求，浏览器之外的程序不受影响；同一个环境里装多个接管网络的扩展，规则还可能互相冲突，排查起来很费劲。还要留意失效状态：扩展被停用、更新失败或者崩溃时，流量往往直接走本地网络出去，真实地址就露了。环境多的时候，每个环境都要装一遍、维护一遍，成本也不低。
协议和认证上最容易出问题的地方
代理地址是 SOCKS5，客户端却按 HTTP 代理去连，或者反过来，最常见的表现就是参数明明填对了却连不上。这类错不用怀疑 IP，先看协议类型有没有对上。
HTTP 和 HTTPS 代理兼容性最好，但需要账号密码时会弹认证窗口。无人值守或者批量操作时，这个弹窗会卡住流程，有的工具支持把凭据写在地址里来绕开，不同工具的写法还不统一，容易填错格式。
SOCKS5 在配置里直接带凭据，不弹窗，转发流量的类型也更全，混合流量场景更省事。至于出口类型，固定 IP 的数据中心代理速度快、成本较低，适合自动化和批量账号；固定的 ISP 住宅代理更像真实用户，适合长期运营；动态住宅按流量计费、地址可切换，适合注册、采集这类短期任务。
四件事验完才算配好
看到浏览器能打开网页，不代表代理生效了。出口地址是否与预期一致、DNS 解析是否也走了代理、IPv6 环境下是否暴露了真实地址、WebRTC 有没有带出本地网络地址，这四项都要过一遍。任何一项漏掉，表面上能上网，身份其实已经露在外面。
还有一层是参数之间要对齐：出口归属地要和账号注册地区一致，时区跟着出口走，语言跟目标市场一致。只改 IP 不动其他设置，等于没改。
怎么选
单账号、临时测试，全局代理就够了。账号数量多、要长期维持固定身份，环境级绑定更合适——这种场景下代理和环境的对应关系需要被集中管住，PurpleMark 这类工具把绑定关系收在一个环境列表里，改配置时不容易串号。需要按站点分流、做多地区对比，再考虑插件级代理，并且要接受它只覆盖浏览器内流量这个前提。
