如果你遇到过“Chrome 已经走另一条网络，但微信、游戏、系统更新还是原来的出口”，问题通常不在端口，而在于你混淆了代理和网关。把这篇看懂，后面很多网络问题会突然简单。
最重要的一句话：代理通常是“某个软件主动把连接交给代理”；网关是“操作系统根据路由把数据包交给下一跳”。一个偏应用，一个偏整台设备的网络路径。 先看一个最常见的现场。 PC B 的 Chrome 设置了： HTTP Proxy → 192.168.1.100:8080 Chrome 打开网站时，流量经过 Windows A，再从 Windows A 已连接的 VPN 出去。 但 PC B 上的另一个软件没有代理设置，它还是直接使用 PC B 自己的网络。 Chrome → HTTP Proxy → Windows A → VPN 微信 / 其他软件 → PC B 自己的默认网络 很多用户看到这里会问： “不是已经设置代理了吗？为什么整台电脑没有一起走？” 因为代理根本不是这么工作的。 代理：应用程序自己决定“先交给谁” 以 HTTP Proxy 或 SOCKS5 为例，真正知道代理地址的通常是应用程序。 Chrome 知道代理是 192.168.1.100:8080，所以 Chrome 主动连接这个地址。 数据库工具如果配置了 SOCKS5，也会主动连接 192.168.1.100:1080。 但一个完全不知道代理存在的软件，不会神奇地自动绕去代理。 通俗比喻： 代理像“指定代办人”。你告诉 Chrome：“以后办这类事先去找老张。”Chrome 会照做。但你没有告诉其他软件，其他软件当然还是自己办。 所以应用代理最关键的前提是： 应用本身支持这个代理，或者有其他程序替它把流量接进代理。 这也解释了为什么 Windows 的“系统代理”不等于“系统所有网络流量”。系统代理只是提供了一套代理配置；哪些应用会读取并遵守它，取决于应用实现。 网关：操作系统不知道往哪发时，就把包交给它 默认网关（Default Gateway） 是另一套逻辑。 Windows 在发送一个 IP 数据包之前，会看自己的路由表。目标如果就在本地网段，可以直接发；如果目标属于其他网络，又没有更具体的路由，就通常交给默认网关。 在 Microsoft Learn 的 TCP/IP 地址与子网说明里，默认网关就是主机把远程网络流量交给下一跳的重要配置。 应用程序产生 IP 流量↓ Windows 路由表判断目标↓ 本地网络？直接发送或 远程网络？交给匹配路由 / 默认网关 这里和 HTTP、SOCKS5 完全不同： 应用程序甚至不需要知道“默认网关是谁”。它只负责建立连接，操作系统的 IP 路由负责决定数据包下一步去哪。 这就是为什么“网关模式”更接近整台设备级别。 只要路由设置正确，很多应用不需要逐个填写 HTTP/SOCKS5 代理，也能把 IP 流量交给网关处理。 NAT 又是什么？它不是网关的同义词 这几个词经常一起出现，所以很多人会混成一件事。 网关回答的是： “数据包下一跳交给谁？” NAT（Network Address Translation，网络地址转换）回答的是： “数据包经过这里时，要不要把源地址或目标地址改写？” 例如家庭路由器让几十台内网设备共享一个公网 IPv4，通常就会做 NAT。NAT 的核心是地址转换。更深入的网络层概念可以参考 Cloudflare Learning Center 的路由器与网络层说明，以及文末的 NAT 参考资料。 但技术上： 网关 ≠ NAT。 路由器可以只做路由而不做 NAT；NAT 常常运行在网关上，但它是另一项功能。Windows ICS 属于比较典型的“共享连接 + 路由/NAT”使用场景，所以普通用户经常把几件事一起看到。 VPN 又放在哪里？ VPN 也不是“代理的高级版”。 大多数现代 VPN 客户端会通过虚拟网卡、隧道接口或系统路由，把指定的 IP 流量送进 VPN 隧道。 有的 VPN 是： 全隧道（Full Tunnel） —— 大量甚至全部外部流量走 VPN。 有的 VPN 是： 分流（Split Tunnel） —— 只有公司网段、指定目标或指定应用走 VPN，其他流量仍走本地网络。 所以当 Windows A 已经连好公司 VPN 时，NetConfiger 当前产品可以做的，是把 Windows A 已经能访问的这条网络，通过 HTTP / SOCKS5 给其他支持代理的软件复用。 这和“让 Windows A 直接成为 PC B 的透明默认网关”是两种产品能力，不能混着说。 如果你现在更想先弄懂应用代理本身，可以分别看 HTTP Proxy 和 SOCKS5。这两篇解释的是“应用怎么把连接交给代理”，而这一篇解释的是“为什么那不等于整台设备都换了网络路径”。
从真实拓扑看更容易分清：代理模式下，PC/VM 的具体软件主动连接 NetConfiger；完整网关模式则是客户端把网络层流量交给网关。
TUN 又是什么？为什么很多 VPN 看起来能“整机接管”
TUN 可以简单理解成一种虚拟的三层网络接口。程序可以把 IP 数据包送进这个虚拟接口，再由用户态网络程序决定如何封装、转发或送入其他隧道。
对普通应用来说，它通常不需要知道 SOCKS5 地址，也不需要每个软件单独填写 HTTP Proxy。应用照常联网，操作系统路由把相应数据包送进 TUN。
所以从用户体验上看：
| 方式 | 谁知道这条“特殊网络” | 常见效果 |
|---|---|---|
| HTTP Proxy | 应用程序 | 支持 HTTP Proxy 的软件使用它 |
| SOCKS5 | 应用程序 | 支持 SOCKS5 的软件使用它 |
| 系统代理 | 读取系统代理设置的应用 | 并非全系统所有流量 |
| TUN / VPN 路由 | 操作系统路由 + 虚拟接口 | 可接管更广泛的 IP 流量 |
| 默认网关 | 操作系统 IP 路由 | 客户端通常无需逐应用填写代理 |
用几个真实问题判断，你需要的是代理还是网关
场景 1：另一台电脑只要 Chrome 打开公司后台
用 HTTP Proxy 就很自然。没有必要为了“整机”引入更复杂的路由。
场景 2：数据库工具要连公司内网 3306
如果数据库工具支持 SOCKS5，可以使用 SOCKS5。它需要的是应用级 TCP 代理。
场景 3：PC B 上 20 个软件都要自动走 Windows A
逐个填代理就会很麻烦，而且有些软件根本不支持代理。这时候应该考虑网关、TUN、透明转发或系统级方案。
场景 4：电视、游戏机、IoT 完全没有代理设置
HTTP/SOCKS5 通常不是完整方案。设备需要把 Windows/路由器当作网络层出口，或者通过其他可控网关使用目标网络。
场景 5：Chrome 已经走代理，微信为什么没走？
因为 Chrome 知道代理地址，微信未必知道或遵守相同代理设置。此时首先不是“代理坏了”，而是要确认微信有没有使用代理的机制。
把代理、VPN、网关放到一张图里
| 概念 | 一句人话 | 主要控制层面 | 是否通常需要逐应用支持 |
|---|---|---|---|
| HTTP Proxy | 帮网页/Web 软件中转连接 | 应用 | 是 |
| SOCKS5 | 更通用地帮软件建立 TCP/部分 UDP 连接 | 应用 | 是 |
| VPN | 在本机建立到另一网络的隧道，并通过路由把流量送进去 | 系统/网络 | 通常不需要逐应用代理设置 |
| 默认网关 | 不知道目标在哪时，系统默认把 IP 包交给它 | 网络 | 否 |
| NAT | 转发过程中改写网络地址 | 网络 | 否 |
| TUN | 把 IP 包交给虚拟网络接口处理 | 系统/网络 | 通常否 |
所以“浏览器走 VPN，其他软件没走”很多时候不是 VPN 的问题，也不是代理失效，而是：你只给浏览器设置了应用代理，却期待它产生网关级效果。
专业资料 / 进一步阅读
Microsoft Learn — TCP/IP addressing and subnetting（含 Default Gateway） Cloudflare Learning — What is a router?（通用网络基础） Wikipedia — Network Address Translation Wikipedia — Proxy server
NetConfiger 当前已经上线的 VPN Sharing 主要属于 HTTP / SOCKS5 应用级分享：需要下游软件支持并使用代理。完整的网关模式属于另一层网络能力，不能因为都叫“分享网络”就把两者当成同一件事。