跳到主要内容

Windows 多代理分流实战:Telegram 固定走 Hiddify,其他软件走 v2rayN,Proxifier 接管不支持代理的程序


Windows 多代理分流实战

我的目标很简单:Telegram Desktop 固定走 Hiddify,浏览器和大部分软件继续走 v2rayN,少数完全不支持代理设置的软件再交给 Proxifier。

这类需求最容易出问题的地方不是“代理不会配”,而是几个客户端都在抢 Windows 系统代理、TUN、DNS 和默认路由。最终结果往往是单独开谁都能用,一起开就断网。

本文按 2026 年 10 月的实际软件状态重写。Hiddify 当前桌面版已经进入 4.x,v2rayN 7.25 系列也对核心、TUN 和代理链做了不少调整,因此不再照搬早期教程里的固定端口和旧 UI 名称。

原则只有一条:同一时间只让一个程序接管系统级流量,其他代理客户端只提供本地 SOCKS/HTTP 端口。

一、先把三种分流方式分清楚

Windows 上常见的代理接管方式可以分成三层:

方式 谁来决定流量走哪 适合什么
应用内代理 应用自己 Telegram、浏览器、下载器等支持 SOCKS/HTTP 的程序
系统代理 Windows / WinINET 大量遵循系统代理的桌面程序
TUN 虚拟网卡 / 路由 UDP、游戏、以及不遵循系统代理的流量
Proxifier 按进程拦截 TCP 连接 不支持代理设置、但主要使用 TCP 的桌面程序

如果 Telegram 本身就支持 SOCKS5,那么优先使用 Telegram 自带代理,没必要先上 Proxifier。

如果某个软件完全没有代理设置、而且主要是 TCP 连接,可以再考虑 Proxifier。Proxifier v4 的主要能力是代理 TCP 连接和 DNS,并不能替代 TUN 去接管任意 UDP 流量。

需要 UDP、游戏或更完整的 IP 层接管时再考虑 TUN;同时开多个 TUN 最容易和路由表、DNS 发生冲突。

本文推荐的最终结构是:

Telegram.exe ──SOCKS5──> Hiddify 本地 mixed 端口 ──> Hiddify 节点

浏览器/普通软件 ──Windows 系统代理──> v2rayN ──> v2rayN 节点

特殊程序.exe ──Proxifier 规则──> 指定的 Hiddify / v2rayN 本地端口

这样 Hiddify 与 v2rayN 都可以同时运行,但只有 v2rayN 修改 Windows 系统代理。

二、Hiddify 只负责提供本地代理端口

Hiddify 当前桌面端基于 sing-box,也可以配合 Xray。Windows 上建议先确认客户端真实监听端口,不要死记旧教程里的固定值。

在 Hiddify 的设置中查看类似:

Mixed Port
SOCKS Port
HTTP Port

当前常见 mixed 端口仍可能是:

127.0.0.1:12334

但以你自己的客户端界面为准。

为了和 v2rayN 共存,建议:

Hiddify:关闭 Set System Proxy
Hiddify:关闭 TUN / VPN mode
Hiddify:保持客户端已连接
Hiddify:只把本地 SOCKS/HTTP 端口提供给指定应用

如果你确实要让 Hiddify 开 TUN,那么 v2rayN 就不要再开 TUN,否则两个虚拟网卡和路由规则很容易互相覆盖。

Hiddify 4.x 的 Windows 版本仍支持 TUN,但桌面端按应用分流并不像 Android 那样天然方便,因此 Windows 上“本地端口 + Proxifier / 应用自带代理”反而更容易维护。

三、Telegram Desktop 固定走 Hiddify

Telegram Desktop 自带代理设置,所以它是最好处理的。

打开 Telegram:

Settings
→ Advanced
→ Connection type
→ Use custom proxy

添加 SOCKS5:

Host: 127.0.0.1
Port: Hiddify 当前实际 SOCKS/mixed 端口
Username: 留空
Password: 留空

例如 Hiddify mixed port 为 12334:

127.0.0.1:12334

保存后 Telegram 会直接把自己的连接交给 Hiddify,而不关心 Windows 系统代理现在指向哪里。

测试时最简单的方法是:

1. v2rayN 正常运行
2. Hiddify 正常运行
3. Telegram 自定义 SOCKS5 指向 Hiddify
4. 分别切换 Hiddify 节点,观察 Telegram 连接是否跟着变化

如果 Telegram 关掉自定义代理后还能正常使用,而打开后立即失败,优先检查 Hiddify 的本地端口,不要先怀疑 Telegram。

四、v2rayN 继续负责 Windows 系统代理

v2rayN 这一侧保持普通用法即可:

系统代理:自动配置系统代理
路由:按自己的规则使用
TUN:如果没有必要,先关闭

这样浏览器、Git 客户端以及遵循 Windows 系统代理的程序继续走 v2rayN。

v2rayN 当前 7.25 系列已经更新到新的 Xray 配置格式,并继续支持 Xray-core 与 sing-box-core。日常分流时不需要因为版本升级就重新设计整套网络,只要确认:

1. 本地监听端口没有和 Hiddify 冲突
2. 系统代理只有 v2rayN 在写
3. Hiddify 没有偷偷开启 TUN

查看监听端口可以用:

Get-NetTCPConnection -State Listen |
  Where-Object { $_.LocalAddress -in @('127.0.0.1','0.0.0.0') } |
  Sort-Object LocalPort |
  Select-Object LocalAddress,LocalPort,OwningProcess

再配合:

Get-Process -Id <PID>

确认端口到底属于 Hiddify、v2rayN 还是其他程序。

五、没有代理设置的软件交给 Proxifier

Proxifier v4 的核心就是“按进程、目标地址、端口决定 Direct / Proxy / Chain / Block”。

先在:

Profile → Proxy Servers

添加两个本地代理,例如:

Hiddify-local  = 127.0.0.1:<Hiddify端口>  SOCKS5
v2rayN-local   = 127.0.0.1:<v2rayN端口>   SOCKS5

然后进入:

Profile → Proxification Rules

建议保留最前面的 Localhost 规则为 Direct。不要把 127.0.0.1 再送进代理,否则非常容易形成本地回环。

例如某个程序只想走 Hiddify:

Name: Only-Hiddify
Applications: app.exe
Target hosts: Any
Target ports: Any
Action: Proxy Hiddify-local

其它程序保持:

Default → Direct

如果你希望 Proxifier 接管的大部分程序都走 v2rayN,也可以把 Default 设为 v2rayN-local,但这种模式下必须把以下程序加入 Direct:

Hiddify.exe
v2rayN.exe
xray.exe
sing-box.exe
cloudflared.exe

否则代理客户端自己的出站又被送回自己,典型结果就是无限循环、CPU 升高或者所有连接超时。

Proxifier 的规则从上到下匹配,因此“更具体”的应用规则应放在 Default 之前。

六、Telegram 到底用自带代理还是 Proxifier

推荐顺序:

Telegram 自带 SOCKS5 > Proxifier > TUN 强制分流

原因是 Telegram 自带代理最简单,也不会影响其它应用。

只有在你希望 Telegram 的全部子进程、更新程序或其它相关连接统一由同一规则处理时,才有必要让 Proxifier 按 Telegram.exe 做进程级接管。

七、最常见的故障

1. 两个客户端都开系统代理

症状:一会儿 Hiddify 生效,一会儿 v2rayN 生效,退出一个以后另一个也异常。

处理:只保留一个客户端接管系统代理。本文方案里就是 v2rayN。

2. 两边都开 TUN

症状:网络间歇中断、DNS 失效、游戏或本地服务异常。

处理:只保留一个 TUN。按应用分流时优先不启用 TUN。

3. Proxifier 把代理客户端自己又代理了一遍

症状:连接全部超时、Proxifier 日志重复访问 127.0.0.1、CPU 升高。

处理:Hiddify.exe、v2rayN.exe、xray.exe、sing-box.exe 以及 localhost 全部 Direct。

4. 端口写死导致升级后失效

不要把 12334、10808、10809 当成永远不变。升级后先看客户端当前监听设置,再修改 Telegram / Proxifier。

5. Telegram 明明连上了,但出口 IP 不是预期

先确认 Telegram 自定义代理确实处于启用状态,再切换 Hiddify 节点观察变化。不要只看 Windows 系统代理,因为 Telegram 此时已经绕过它。

八、我现在最推荐的组合

v2rayN
  └── 接管 Windows 系统代理

Hiddify
  └── 不接管系统代理,不开 TUN,只提供本地 SOCKS/mixed 端口

Telegram
  └── 内置 SOCKS5 → Hiddify

Proxifier
  └── 只接管没有代理设置的少数程序

这种配置的好处是边界非常清楚。哪一层出问题,就只检查那一层,不会出现“所有流量都被三个软件同时碰一遍”的情况。

九、参考资料


文章作者: 0xdadream
版权声明: 本博客所有文章除特別声明外,均采用 CC BY 4.0 许可协议。转载请注明来源 0xdadream !
赏
评论

评论将在接近此处时加载,也可点击立即加载。

  目录