系统代理是什么，为什么开启后还有软件不走代理？
系统代理是一组供应用读取的代理设置，不能强制所有软件采用同一条网络路径。常见设置包括代理主机、端口、例外地址或自动配置脚本。客户端把本机代理入口写入系统后，遵循这些设置的应用才会把请求交给入口。
不同软件使用的网络库、自身设置和运行环境可能不同。浏览器能打开网页，命令行工具却失败，首先要检查命令行工具是否读取系统代理或代理环境变量，而不是直接判断节点失效。应用也可能自行设置代理，覆盖系统设置。
微软对WinINet与WinHTTP的比较说明，不同网络接口的配置方式有区别。这只是Windows中的一个例子，不能据此推断所有Windows应用的行为，更不能套用到macOS、Linux或手机。
TUN是什么，它与系统代理如何接收流量？
TUN是一种虚拟网络接口，程序可从中读写IP数据包；系统代理则让应用主动连接代理入口。可以把两者理解为两种入口：一个依靠应用按设置发请求，一个依靠操作系统的路由把相应流量交给虚拟接口。
Linux内核TUN/TAP文档区分了处理IP包的TUN与处理以太网帧的TAP。代理客户端还需要处理这些包、建立出站连接并转发数据。创建了接口，只完成了接管链路中的一部分。
在Android上，客户端通常通过系统的VpnService接口建立本地TUN并请求用户授权。桌面系统可能需要服务或管理权限，具体以客户端官方说明为准。同样叫TUN的开关，在不同平台上也可能有不同的权限和实现条件。
系统代理和TUN分别适合什么场景？
应用能正常使用代理设置时，系统代理往往更容易验证；需要处理不读取代理设置的应用时，再考虑TUN。不要仅凭模式名称选更复杂的方案，先看实际需要接管的软件。
| 观察项 | 系统代理 | TUN |
|---|---|---|
| 流量进入方式 | 应用采用系统提供的代理配置 | 被系统路由到虚拟接口的IP流量交给程序 |
| 常见排查起点 | 应用是否读取设置、入口地址和端口是否正确 | 接口和路由是否建立、权限与排除规则是否符合预期 |
| 需要关注的影响 | 代理例外、应用自带设置、退出后的设置恢复 | 局域网访问、其他VPN、DNS、IPv4与IPv6覆盖范围 |
例如，只需要浏览器和一个支持显式代理的开发工具，可以先分别确认它们的代理设置。某个应用没有代理选项，再检查客户端是否提供适用的TUN接管。客户端的安装和权限步骤可参考Clash Verge Rev指南或v2rayN指南。
开启TUN或全局模式，就代表全部流量都经过远端吗？
不代表。接管范围、客户端分流和实际出站是三个需要分别确认的环节。流量进入TUN后，规则仍可以让它直连、代理或拒绝；没有进入客户端的流量，也不会因为切换了客户端的全局模式而自动被接管。
v2rayN官方说明明确区分系统代理入口与核心路由。不同客户端的“全局”含义还要看其实现和配置，不能把一个工具中的标签当成所有工具的统一标准。
TUN接管本身也可能有限制。IPv4与IPv6的路由、应用排除、目标地址排除和DNS处理都会影响实际范围。比如sing-box TUN配置支持自动路由、指定路由和排除路由等选项。因此“网卡已创建”与“某个应用的请求已经过指定出口”是不同的验证结果。
手机显示VPN图标，或者开启TUN，就说明连接安全了吗？
VPN图标或TUN状态说明系统接管机制在运行，不能单独证明远端已连通、所有流量已加密或身份完全匿名。Android VPN接口还允许应用配置接管名单和路由，图标不会替用户逐一核实这些范围。
TUN负责把包交给程序，不自带某一种远端加密协议。数据是否受到保护，还取决于应用到网站的HTTPS、客户端到远端的传输协议、证书验证和实际配置。TLS 1.3标准描述的是通信双方之间的安全通道，并不把网页安全、设备安全和代理接管范围合并成一个保证。
实用的判断方法是分别看接管状态、真实请求结果与证书错误。如果网页报告证书不可信，应核对设备时间、目标域名和证书链。把校验关闭后“能打开”不能作为安全验证完成的证据。
怎样验证某个应用真的经过了预期的代理路径？
用实际应用发起请求，并把请求结果与客户端连接记录对照。只看开关、节点延迟或一个浏览器中的出口IP，不能证明另一款应用也采用相同路径。
- 先记录当前接管方式、分流模式和选中的出口，暂停其他会改变路由的客户端，减少相互影响。
- 客户端提供本机HTTP或SOCKS入口时，确认入口正在监听；需要显式验证时，到验证命令工具填写客户端显示的实际协议和端口，不套用别人的默认值。仅提供TUN的工具可直接用实际应用与连接记录对照。
- 对同一个可用目标发起一次显式代理请求，再用需要排查的应用访问。记录时间、域名、报错和成功或失败。
- 在客户端连接记录中查看该目标是否出现、命中了什么规则、最终使用哪个出口。应用缓存或连接复用会影响观察，可重新发起连接再比较。
如果显式代理请求成功，应用请求却不出现在记录中，重点查应用接管。如果记录已经显示代理出站但目标仍失败，就继续查DNS、远端连接或目标服务。出口IP变化可以补充证据，但只代表这次请求的出口。
应该先开哪一种，切换后断网又怎样恢复？
先选能满足需求、容易验证的一种方式；切换时一次只改变一个条件。可以先验证显式代理，再验证系统代理，确有未接管应用时再测试TUN。这样能区分入口问题与出站问题，避免同时改模式、DNS和规则后失去比较依据。
启用TUN前，记下原有VPN、代理和局域网访问情况。办公室网络、远程桌面、打印机或开发容器可能依赖特定路由，测试时应一起检查，而不能只验证公网网页。TUN与系统代理是否可以同时开启，要看客户端是否设计为支持该组合。
发生断网时，先从客户端停止接管并正常退出，检查系统代理是否仍指向已停止的本机入口，再确认其他VPN和网络连接状态。不要直接删除所有网络接口或把路由表清空。恢复后回到上一个可用配置，保留脱敏错误信息，按网络故障分层排查逐步定位。
常见问题
浏览器能用，终端不能用，必须开启TUN吗？
不一定。先检查终端工具是否支持显式代理或代理环境变量，并使用实际入口做验证。如果显式代理成功，问题通常在终端的代理配置；确有无法配置代理的应用时，再考虑TUN。
系统代理和TUN可以同时开吗？
部分客户端支持同时启用，但不是通用要求。遵循具体客户端的说明，先分别验证再组合；其他VPN、重复接管和不合适的路由可能造成冲突。
TUN模式是不是一定比系统代理更快？
没有这种保证。两者首先是接管方式的区别。实际性能还取决于实现、设备、协议、出站网络和目标；应在相同目标与配置下测量，不能根据开关名称判断。
为什么TUN已开启，但局域网设备反而访问不到？
检查局域网地址是否被新路由接管，以及客户端是否有适当的排除或直连规则。先停用TUN比较现象，再核对实际路由和配置，避免直接改动整张路由表。
全局模式是否能接管忽略系统代理的软件？
单独改变客户端出站模式不能保证接管这些软件。必须先让流量通过应用代理设置或适用的TUN等入口进入客户端，出站模式才会对这部分流量生效。
退出客户端以后断网，应该先检查什么？
先检查系统代理是否仍指向已经停止监听的本机端口，再查看残留VPN连接和路由状态。优先使用客户端的正常停止与恢复功能，并保留原配置作为比较依据。
官方来源与核对
本文依据以下标准与官方资料整理，资料核对日期为 2026.10.02。概念说明与具体软件实现有区别，实际设置仍需对照对应版本文档。