很多人第一次接触代理IP，都是这么操作的：照着教程在系统设置里填了一个代理地址，又在代码里写了一份代理配置，浏览器插件里还留着一个，结果一跑程序就报错——要么连不上，要么速度慢得离谱，要么干脆不知道自己到底从哪个IP出去的。这就是典型的代理IP设置冲突。
这篇就把"全局代理"和"局部代理"这两条路讲清楚，告诉你什么时候该用哪个，以及怎么设置才能不打架。
一、代理IP为什么会"冲突"？先弄清三层作用范围
想把代理设置明白，得先知道代理是在哪一层生效的。日常能接触到的，大致有三层：
第一层是系统层。在操作系统或浏览器设置里填了代理，整台设备的上网流量都会往代理走，这就是通常说的全局代理。它的特点是"覆盖广"，但也最容易把本来不需要走代理的请求一并带出去。
第二层是进程层。只让某一个软件、某一个浏览器、某一段程序走代理，其他程序照常直连。大多数开发场景、多账号运营场景用的都是这一层。
第三层是请求层。同一个程序里，这一次请求用A代理，下一次请求用B代理，甚至可以按目标域名决定走不走代理。这是最灵活的一层，也是精细化管理的主力。
所谓"冲突"，本质就是多层同时生效，互相覆盖或者互相叠加。比如系统层开了一个代理，程序里又指定了一个，请求就会先经过第一层再绕到第二层，形成链式代理，速度掉一半不说，很多目标服务看到这种异常的出口路径，直接就把请求拒了。
还有一类冲突不是"层"的问题，而是"资源"的问题：同一个代理IP被多个账号、多个任务同时抢着用，目标服务器那边看起来就是一串高频异常访问，于是被限制、被要求验证。这种情况你查配置查不出毛病，因为配置本身没错，是IP的使用方式冲突了。
二、全局代理和局部代理，到底差在哪
先看一张对比表，心里有个数：
| 对比项 | 全局代理 | 局部代理 |
|---|---|---|
| 作用范围 | 整台设备的所有流量 | 仅指定程序或指定请求 |
| 配置位置 | 系统设置、浏览器设置 | 代码参数、启动参数、插件规则 |
| 影响面 | 大，一旦出错全线受影响 | 小，出问题只影响单个任务 |
| 冲突概率 | 高，容易和其他配置叠加 | 低，隔离性好 |
| 适合场景 | 整机需要统一出口、临时验证 | 多任务并行、多账号运营、采集抓取 |
全局代理的优点只有一个字：省事。填一次，全设备生效，适合临时测试或者整机确实需要统一出口的情况。但缺点也很明显——所有程序都被"绑"在同一条出口上，一旦这条线路抖动或者被限速，整台机器都跟着受影响；而且系统层配置往往优先级很高，你在代码里再指定代理，很容易变成"叠加"而不是"替换"。
局部代理则是把一个代理"关"在指定的范围内。程序A用自己的IP，程序B用另一个IP，互不干扰。多账号、多任务、采集抓取这类工作，基本都应该走局部。
结论其实很直接：临时看效果用全局，长期跑业务用局部。真正需要"不冲突"的，几乎都是局部代理的场景。
三、设置不冲突的核心原则：同一时刻只留一层
不管用哪种方式，记住这条铁律：同一个请求，只能有一条代理生效路径。
具体做法可以按这三步来：
1. 先清空系统层。如果你打算在程序里指定代理，就先把系统设置、浏览器设置里的代理关掉，把环境变量里的代理配置也清一遍。很多"明明改了配置却没生效"的问题，都是因为系统层有个旧配置在默默起作用。
2. 再在进程/请求层配置。用代码参数或者启动参数把代理传进去，作用范围严格限定在这一个程序、这一个任务里。
3. 最后验证出口。跑起来之后，先请求一个能返回出口IP的接口，确认出去的IP是不是你预期的那个。如果不是，说明还有别的层在干扰，回头再查。
# Linux / macOS 临时设置，仅在当前终端会话有效
export http_proxy="http://用户名:密码@代理服务器:端口"
export https_proxy="http://用户名:密码@代理服务器:端口"
# 用完及时清掉，避免和新配置叠加
unset http_proxy
unset https_proxy# Python 中只为单次请求指定代理，作用范围最干净
import requests
proxies = {
"http": "http://用户名:密码@代理服务器:端口",
"https": "http://用户名:密码@代理服务器:端口",
}
resp = requests.get("https://目标地址", proxies=proxies, timeout=10)
print(resp.status_code)注意一个细节：有些程序会同时读取环境变量和代码参数，两者都存在时会优先用其中一种，但另一份并不会消失，等你换个方法调用时它又冒出来了。所以"只留一层"这件事，要靠主动清理来保证，不能指望程序自动帮你选。
四、四种最常见的冲突场景与解法
场景一：系统代理和代码代理同时开着。表现是请求能通，但特别慢，或者部分请求失败。解法很简单，关掉系统层，只保留代码层。
场景二：环境变量残留。表现是换了代理地址却不生效，测出来的出口IP永远是旧的。解法是先把环境变量清空再重新设置，每次切换代理前都做一次清理动作。
场景三：同一个IP被多个任务抢用。表现是前期正常，跑一会儿开始超时、要求验证。这不是配置冲突，是IP资源冲突。解法是给每个任务分配独立的IP，或者用隧道代理让每次请求自动换出口，从机制上避免多个任务挤在同一个IP上。
场景四：认证方式不统一。有的配置用账号密码认证，有的用IP白名单，两套混着用，就会出现"这个程序能连、那个程序连不上"的怪现象。解法是统一成一种认证方式，别在同一台机器上混搭。
顺带提醒一句：端口占用也是隐性冲突源。本地同时跑多个代理客户端时，如果它们都监听同一个本地端口，后启动的那个会直接失败，但错误提示往往很含糊，让人误以为是代理线路的问题。
五、选对代理服务，从源头减少冲突
配置层面的冲突可以靠规范化解，但IP资源层面的冲突，得靠服务本身来解决。
天启HTTP是国内代理IP服务商，提供HTTP、HTTPS、SOCKS5等协议的代理服务，常见的产品形态包括动态短效代理、静态长效代理、独享代理和隧道代理，支持API提取与白名单/账密两种认证方式。对"多任务并行还想不冲突"的场景，它的两个特性比较实用：
一是独享IP。资源不与他人共用，避免了"别人把你的IP用脏了"这种完全不可控的冲突来源。
二是隧道代理。程序只需要配置一个固定的隧道入口，出口IP由服务端按策略切换，你不用在代码里维护一大堆IP列表，也就少了"IP列表更新不及时""同一个IP重复分配"这类配置层面的坑。
具体套餐、并发上限和可提取数量，建议直接到天启HTTP官网核对，按自己的业务量选，不要一次买太多闲置着。
六、上线前先过一遍这份检查清单
把下面几条当成固定动作，基本能挡掉九成以上的冲突问题：
① 确认代理只留一层，系统层和代码层不要同时生效；
② 每个账号、每个任务对应独立的IP，不要串用；
③ 本地代理端口不重复，多开时给每个实例分配不同端口；
④ 控制单IP的并发量，跑批量任务时给请求加间隔；
⑤ 认证方式统一，白名单和账密不要混搭在同一台机器上；
⑥ 每次切换配置后，先测一次出口IP再用。
最后说一句取舍：全局代理适合验证和临时使用，局部代理适合长期业务。如果你做的事需要多个身份、多个出口同时在线，那就别图省事去开全局，把作用范围切小，把IP资源分干净，冲突自然会少一大半。
常见问题
Q：全局代理开着，代码里又指定了代理，会怎么样？
两个都会生效，请求会先走系统层再走代码层，形成链式代理。结果通常是速度变慢、部分请求失败，甚至目标服务器直接把请求判定为异常。正确做法是二选一，长期业务建议只保留代码层。
Q：为什么我改了代理地址，测出来还是原来的IP？
大概率是环境变量或者系统设置里还残留着旧配置，优先级比你新写的那份高。先把所有相关配置清空，再重新设置一份，然后请求一次能返回出口IP的接口确认。
Q：局部代理具体怎么设置才最干净？
把代理写在代码的请求参数里，作用范围最小；如果是命令行工具，用启动参数指定；实在要用环境变量，就只在当前会话里生效，用完即清。
Q：多个任务同时跑，怎么避免互相影响？
两条路：一是给每个任务分配独立的IP，走独享代理；二是用隧道代理，每个任务配同一个隧道入口但由服务端自动切换出口，程序侧配置量最小，也不容易出错。
Q：天启HTTP的代理能用在哪些场景？
它面向国内网络环境，适合数据采集、多账号运营、软件测试、网络请求管理等需要国内IP的场景。不涉及国外IP，也没有住宅类资源，选型前建议先到官网确认产品形态是否匹配你的业务。
Q：代理设置对了但速度还是慢，是不是冲突没解决？
不一定是冲突。先看是不是走了链式代理，再看目标站点的响应时间，最后看单IP的并发量是不是太高。逐项排掉，问题一般都能定位到。
