Thanks to visit codestin.com
Credit goes to henryzhuhr.github.io

Henry's xyz

外观

Clash ​

1. 脚本快速设置 ​

shell
export sys_proxy_lip=192.168.1.95
export sys_proxy_port=7890
# 开启系统代理
proxy_on() {
  export proxy="http://${sys_proxy_lip}:${sys_proxy_port}"

  # HTTP  协议代理 http://代理服务器地址:端口
 export http_proxy=${proxy}

  # HTTPS 协议代理 http://代理服务器地址:端口
  export https_proxy=${proxy}

  # FTP   协议代理 http://代理服务器地址:端口
  # export ftp_proxy=${proxy}

  # 设置所有协议的代理，如果设置了此变量，则无需单独设置其他代理变量。
  # export all_proxy=${proxy} 

  # 指定不需要通过代理的主机或域名，可以使用通配符，多个值之间用逗号分隔
  export no_proxy="localhost, 127.0.0.1, ::1"
 [[ $LANG == *"zh"* ]] && echo -e "\033[32m[√] 开启代理\033[0m" || echo -e "\033[32m[√] Proxy enabled\033[0m"
}
# 关闭系统代理
proxy_off(){
    unset http_proxy
    unset https_proxy
    unset ftp_proxy
    unset all_proxy
    unset no_proxy
    [[ $LANG == *"zh"* ]] && echo -e "\033[31m[×] 关闭代理\033[0m" || echo -e "\033[31m[×] Proxy disabled\033[0m"
}
proxy_off

随后，我们可以通过 proxy_on/proxy_off 命令开启/关闭代理，或者将其添加到 ~/.bashrc 或 ~/.zshrc 中，使其在每次启动终端时自动执行。

2. TUN 模式 ​

2.1 它到底是什么 ​

TUN 不是另一种“代理协议”，而是操作系统提供的三层虚拟网卡。Clash / Mihomo 开启 TUN 后，会创建一个虚拟网络接口，并通过路由把原本直接出网的 IP 流量先导入内核或用户态协议栈，再交给规则系统决定下一步怎么处理。

也就是说，TUN 的本质是“接管流量入口”，不是“强制所有流量都翻墙”：

  • 命中 DIRECT 的流量还是会直连
  • 命中代理规则的流量才会走节点
  • 命中 REJECT 的流量会被直接丢弃

这也是为什么 TUN + 规则模式 和 TUN + 全局模式 的体验完全不同。前者是“所有流量都先进 Clash，再按规则分流”；后者才是“几乎所有流量都被送去代理”。

2.2 它和系统代理有什么区别 ​

系统代理的前提是：应用本身愿意遵守 HTTP / SOCKS 代理设置。但很多程序并不理会这些设置，比如一部分命令行工具、游戏、语音通话、Docker、某些桌面应用和 UWP 应用。

TUN 工作在 IP 层，优点是它不要求应用“自觉”，只要流量能被路由进虚拟网卡，Mihomo 就有机会接管它。因此 TUN 模式通常比单纯设置 http_proxy、https_proxy 或系统代理更彻底。

2.3 TUN 和 TAP 不是一回事 ​

TUN 处理的是三层 IP 包，TAP 处理的是二层以太网帧。前者更像“点对点隧道接口”，后者更像“虚拟网卡 + 交换网络”的入口。

对 Clash / Mihomo 来说，目标主要是接管主机的 IP 流量并做分流，而不是模拟完整二层网络、桥接、ARP 广播或虚拟交换机，所以用 TUN 更合适。TAP 更常见于虚拟机、网桥、二层 VPN 一类场景。

2.4 为什么很多人会开 TUN ​

以下情况通常比单纯系统代理更适合开 TUN：

  • 需要让终端工具也稳定走规则，比如 git、包管理器、go、docker pull
  • 需要接管 UDP 较多的应用，比如外服游戏、语音通话、部分实时应用
  • 希望把 DNS 也纳入统一控制，降低 DNS 泄露概率
  • 不想逐个给应用配置代理，想把“听话”和“不听话”的程序一起纳入规则系统

如果只是浏览器访问网页、看视频，而你的应用本来就支持系统代理，那么不开 TUN 往往更简单，也更少折腾。

2.5 几个常见误区 ​

  • 开了 TUN，不等于开了全局代理。真正决定是否走节点的，仍然是 规则模式 / 全局模式 / 直连模式 以及具体规则本身。
  • 开了 TUN，不等于所有协议都一定能代理。TUN 只能负责“把流量接进来”，但上游节点和出站协议是否支持这类流量，仍然是另一回事，尤其是 UDP。
  • ping 不是验证代理是否正常的好方法。ping 依赖 ICMP，而很多代理协议的主路径并不转发 ICMP。验证 TUN 更适合用浏览器、curl、git、包管理器或目标应用本身。
  • TUN 常常需要管理员权限或安装系统服务；防火墙、虚拟机软件、其他 VPN、抓包工具也可能和它抢路由或网卡控制权。

2.6 Mihomo 里最值得关心的几个配置项 ​

最常见、最值得理解的是下面几个字段：

  • enable：是否启用 TUN
  • stack：TUN 使用的协议栈，默认值是 gvisor，如无特殊问题建议优先尝试 mixed
  • auto-route：自动下发路由，把流量导入 TUN
  • auto-detect-interface：自动识别当前出口网卡
  • dns-hijack：把 DNS 请求导入 Mihomo 内部 DNS 模块
  • strict-route：在启用 auto-route 时使用更严格的路由规则，主要用于减少泄露
  • auto-redirect：仅 Linux 可用，会自动配合 iptables / nftables 做 TCP 重定向

协议栈可以简单这样理解：

  • system：使用系统协议栈，兼容性和整体完成度通常更好，占用也更低
  • gvisor：用户态协议栈，隔离性更强，在某些场景下会有更好的网络处理性能
  • mixed：混合堆栈，TCP 走 system，UDP 走 gvisor，官方文档建议无特殊问题时优先尝试它

如果从“怎么选”来理解，可以简单按下面判断：

  • 优先尝试 mixed：适合作为桌面场景的第一选择，兼顾 TCP 兼容性和 UDP 体验
  • 遇到和系统协议栈相关的问题时，试 gvisor：它更偏用户态实现，隔离性更强，但少数应用行为可能和系统栈不同
  • 追求更低开销、或者明确需要系统栈行为时，试 system：它通常更贴近真实系统网络语义，但也更依赖系统防火墙和内核路径

如果系统防火墙开启，system 和 mixed 可能需要额外放行才能正常工作。Mihomo 官方文档给出的处理方式是：

  • Windows：在防火墙里放行相关内核
  • macOS：如遇到问题，可在防火墙选项里手动放行 mihomo app
  • Linux：如遇到问题，可尝试放行 TUN 网卡的出站流量

一个比较稳妥的起步配置可以写成：

yaml
tun:
  enable: true
  stack: mixed
  auto-route: true
  auto-detect-interface: true
  dns-hijack:
    - any:53
    - tcp://any:53
  strict-route: true

如果你在 Linux 上，并且希望更彻底地接管 TCP 流量，可以再考虑：

yaml
tun:
  auto-redirect: true

但这项配置依赖 Linux 的 iptables / nftables 机制，不是跨平台通用选项。

2.7 实际理解：TUN 改变的是“进入 Clash 的方式” ​

可以把系统代理理解成“只有认识代理协议的应用，才会主动走到大厅门口”；而 TUN 更像是在系统路由层面加了一个入口，让更多原本不会理会代理设置的流量，也先被送到 Clash 门口排队。

后面究竟是直连、代理，还是拦截，仍然由规则决定。所以 TUN 模式最准确的理解应该是：

它解决的是“谁能被接管”，不是“所有流量都必须翻墙”。

在 Clash Verge Rev 这类图形界面里，点击开启 TUN，本质上做的也是这些事：安装系统服务、创建虚拟网卡、下发路由、把更多流量导入 Mihomo。

⏰ 最后更新于: