核心结论：设置了系统代理，不等于所有软件都会走代理。系统代理只是一组供软件读取的配置，是否生效取决于每个软件自己的实现、当前设置和请求规则；要覆盖不读系统代理的软件（游戏、命令行工具、多数桌面应用），需要在进程级代理或TUN虚拟网卡层接管流量。
在Windows中设置系统代理后，浏览器查到的IP变了，其他软件却未必跟着变化——这是配置代理时最常见的困惑之一。系统代理写在操作系统层面，但它本身不会自动改写所有软件的连接方式。本文把"系统代理、软件代理、客户端接管"三层机制讲清，给出覆盖范围从小到大的完整图景，以及逐软件核对是否走代理的实操方法，帮你判断业务流量到底有没有"漏走"本地网络。
一、系统代理是什么：一组配置，不是一道命令
系统代理写在操作系统层面（Windows的"设置→网络和Internet→代理"），但它本身不会自动改写所有软件的连接方式。它只是把代理的地址、端口等信息放在系统里，用不用、怎么用，由每个软件自己决定。所以"设置了系统代理"和"所有请求都经过代理"是两件事——前者是提供了一组配置，后者要看每个软件是否读取并遵循它。
按对系统配置的响应情况，软件可分三类：读取系统代理配置、且请求符合代理规则的，通常会使用；设置了独立代理或明确选择直连的，按软件自身配置执行；根本不读取这组系统配置的，不会仅因系统代理开启而自动使用。例如，Windows上的Chrome和Edge通常使用系统代理配置，但也可能受扩展、启动参数或管理策略影响；Firefox可以选择跟随系统、独立配置或直连；命令行工具则要看自身说明，可能使用环境变量、配置文件或命令参数。
二、覆盖范围三层模型：从"浏览器代理"到真全局
为什么"全局代理"有时不全局？答案在覆盖范围的层级上。按覆盖能力从小到大，代理生效方式分三层。
第一层，系统代理（应用层）：在操作系统设置中配置代理地址，所有"读得懂"系统代理设置的应用自动走代理。浏览器、部分办公软件通常没问题，但游戏、命令行工具、系统更新和许多桌面应用根本不读系统代理，流量直接走本地网络。如果只在系统设置里填了HTTP代理，实际效果约等于"浏览器代理"。
第二层，进程级代理（SOCKS5）：通过Proxifier这类工具，强制指定某个进程的所有流量走SOCKS5代理。它不依赖应用是否支持系统代理，而是从网络层拦截指定进程的流量，SOCKS5同时支持TCP和UDP，覆盖绝大多数应用场景。
第三层，TUN模式（虚拟网卡）：通过创建虚拟网卡，在系统层面接管所有网络流量。无论应用是否支持代理，所有数据包都会被路由到代理通道，这是真正意义上的"全局"——连那些不读系统代理的游戏和工具也会被强制接管。相应地，TUN需要管理员权限安装虚拟网卡驱动，并可能与安全软件、其他VPN的路由表产生冲突。理解了这三层，就能解释大多数"开了全局但某软件没用"的情况。
三、一个隐蔽断裂点：WinInet与WinHTTP是两套API
即使软件"愿意"读系统配置，还有一个极其隐蔽的断裂点。Windows的代理设置分为两套独立的API：WinInet由"Internet选项"控制，影响Chrome、Edge等浏览器；WinHTTP由系统服务、Windows更新及多数命令行工具使用。设置系统代理时，大多数软件只修改了WinInet注册表——这意味着浏览器正常走代理，但系统底层请求依然直连，表现为浏览器能打开查询页、命令行工具却行为异常。
同类问题还有组件差异：使用WinHTTP的程序可以获取当前用户的代理配置，也可能采用其他配置方式，实际行为取决于程序实现；自动代理脚本（PAC）还可能对特定地址返回直连规则，即使软件读取系统配置，也不代表每次请求都走代理。"哪些请求被接管"和"被接管后走哪里"是两个问题，有些客户端的"全局模式"只决定已接管流量使用哪条代理，并不自动让所有软件的请求进入客户端。"全局"这个名称本身，不能证明所有连接都已覆盖。
四、逐软件核对清单：浏览器的一次查询代表不了整台设备
核对时，验证对象必须是正在使用的那个软件及其具体请求。三步走：第一步查软件设置，确认是否有独立代理选项，当前采用系统配置、手动配置还是直连，命令行工具还需核对环境变量和启动参数。第二步在软件内验证，支持打开网页或发送请求的软件可访问IP查询服务，其他软件结合自身网络日志和代理连接记录核对——软件调用外部浏览器打开的页面，不能代表它自身的网络连接。第三步对照连接记录，在明确的测试时段发起操作，查看客户端或代理侧记录，记录需要能对应这次请求，只有账号总流量不能单独证明某个软件使用了代理。
一个实用的进阶验证法：在命令行执行路由跟踪命令，观察首跳是否为虚拟网关地址，可以快速确认TUN模式的接管是否真正生效。如果业务涉及亚马逊卖家中心、直播伴侣这类桌面客户端，建议按上述清单逐个核对，避免因流量漏走本地引发登录异常。需要多设备、多软件统一出口的读者，可对照IPdodo代理IP的配置文档确认所用软件的协议兼容性。
五、选型提示：协议与接管方式要一起确认
把机制落到选型上，有两个确认动作。其一，确认软件支持的代理协议：HTTP代理只覆盖网页类流量，需要覆盖游戏、UDP类应用时应选SOCKS5或TUN级方案。其二，确认接管方式与业务的匹配度：轻量浏览场景用"系统自动配置加规则分流"足够，更轻量也更稳定；涉及多桌面客户端的业务环境，优先考虑进程级或TUN级接管，并按软件建立走代理清单。
判断建议：企业环境里还要注意两点——部分安全软件会把虚拟网卡驱动误判为风险程序，需提前加入白名单；系统更新、软件激活等大流量服务建议配置直连规则，避免占用代理带宽。这些细节不决定方案成败，但决定上线后的稳定性。
六、三个常见误区
误区一：浏览器IP变了，其他软件也生效了。不能。浏览器查询至多反映这一次查询的网络来源，其他软件、其他请求仍需分别核对。
误区二：代理客户端开了"全局模式"，就覆盖了所有软件。不一定。全局模式有时只决定已接管流量走哪条代理，实际覆盖范围要看客户端的接管方式与规则。
误区三：命令行工具会自动跟随系统代理。不一定。有些工具用系统配置，有些读环境变量、配置文件或命令参数，需要按工具说明逐一核对。
七、常见问题
Chrome和Edge默认会跟随系统代理吗？Windows上通常会，但扩展、启动参数或管理策略可能改变行为。装了代理扩展也不等于它已经启用或接管设置。
TUN模式和系统代理能同时开吗？不建议。TUN已接管全部流量，同时开系统代理容易造成流量绕行冲突，表现为网页打不开。两者选其一，日常轻量用系统代理，需要全覆盖再切TUN。
Firefox可以单独设置代理吗？可以。Firefox的连接设置可选使用系统代理、手动配置或直连，以当前选项为准。
虚拟机、WSL里的流量会被TUN接管吗？视实现而定，子系统的默认路由可能变化。依赖这些环境时，建议为相关子网显式配置直连或单独策略，避免开发流量误走代理。
结语
系统代理是一组配置而非一道命令：读不读、怎么用，由每个软件自己决定。覆盖范围从系统代理、进程级SOCKS5到TUN虚拟网卡逐层扩大，选型时按业务软件清单匹配接管方式。核对时落实到具体软件和具体请求，浏览器的一次查询代表不了整台设备。想实测验证的读者，可通过IPdodo注册页面开通后按本文清单逐软件核对，确认每条业务流量都走在预期通道上。
