Loading... # 代理节点TUN_Clash模式详解 # 一、概述 ## 1. 简介 ### A. 是什么 本文深入讲解网络代理的核心概念，包括梯子节点、系统代理、TUN 模式以及 Clash 的工作原理，帮助开发者理解网络流量的实际走向。 ### B. 为什么学 - 解决网络调试中遇到的"玄学"问题 - 理解为什么浏览器能翻墙但命令行工具不行 - 掌握 TUN 模式的原理和副作用 - 避免因代理配置不当导致的开发环境问题 ### C. 学完能做什么 - 理解系统代理和 TUN 模式的区别 - 根据场景选择合适的代理模式 - 排查代理相关的网络问题 - 合理配置 Clash 规则 ## 2. 前置知识 ### A. 必备技能 - 基本的网络概念（IP、端口、协议） - 了解 HTTPS 基础知识 - 熟悉命令行操作 ### B. 推荐知识 - 了解代理服务器基本概念 - 使用过 Clash 或类似工具 # 二、核心概念 ## 1. 基本术语 - **梯子/节点**：部署在国外的服务器，用于转发网络请求 - **Clash**：代理管理工具，负责选择节点和路由规则 - **系统代理**：操作系统层面的代理接口规范 - **TUN 模式**：在操作系统底层创建虚拟网卡，强制所有流量走代理 ## 2. 工作原理 ### A. 系统代理模式流程 ```mermaid graph TD A[浏览器] -->|1.访问请求| B[操作系统] B -->|2.系统代理| C[Clash] C -->|3.选择节点| D[代理节点] D -->|4.转发请求| E[目标网站] E -->|5.返回数据| D D -->|6.转发响应| C C -->|7.返回响应| B B -->|8.渲染页面| A ```  ### B. TUN 模式架构 ```mermaid graph LR A[所有程序] --> B[操作系统网络栈] B --> C[TUN 虚拟网卡] C --> D[Clash] D --> E{规则判断} E -->|匹配规则| F[代理节点] E -->|直连| G[直接访问] F --> H[目标服务器] G --> H ```  # 三、系统代理模式详解 ## 1. 节点和 Clash 的角色 ### A. 节点是什么 当你购买梯子服务后，通常会看到多个节点选项，如美国节点、日本节点、新加坡节点等。这些节点本质上是部署在国外的服务器，负责替你访问被限制的内容。 ### B. Clash 的作用 Clash 及其变种（Clash Verge、Clash Meta）的核心作用只有一个：管理这些国外服务器，并根据规则决定什么时候使用哪一台服务器。 ## 2. 系统代理工作流程 当你在 Clash 中开启系统代理后，浏览器访问 Google 的完整流程如下： ### 请求阶段 1. 浏览器发起访问 Google 的请求 2. 操作系统检测到系统代理已开启 3. 将请求转发给 Clash 4. Clash 根据规则选择一个节点（如日本节点） 5. 请求被转发到日本服务器 ### 响应阶段 6. 日本服务器访问 Google 7. Google 返回页面内容给日本服务器 8. 日本服务器将内容转发给 Clash 9. Clash 将内容返回给浏览器 10. 浏览器渲染页面 **关键理解**：你看到的 Google 首页，并不是你的电脑直接访问到的，而是日本那台服务器替你访问的结果。 ## 3. 隐私安全性 ### A. HTTPS 场景 对于绝大多数 HTTPS 网站： - 浏览器与目标网站之间是端到端加密 - 节点服务器只能转发数据，无法解密内容 - 节点最多知道的信息包括： - 你访问了哪个域名 - 数据量大小 - 连接时间 ### B. 安全结论 在正常 HTTPS 情况下，节点服务器看不到你浏览的页面具体内容，因此不必过度担心隐私问题。 # 四、系统代理的局限性 ## 1. 核心问题 系统代理存在一个巨大缺点：浏览器能翻墙，但很多桌面应用、Node 程序、命令行工具无法翻墙。 ## 2. 根本原因 系统代理本质上只是一个"接口规范"，而不是强制规则。可以这样理解： - 浏览器：实现了系统代理这个接口 - Node/大多数桌面 App：没有实现这个接口 ### 行为差异 **支持系统代理的程序**（如浏览器）： - 会主动询问系统："我这个请求要不要走代理？" **不支持系统代理的程序**： - 直接连接目标 IP，不询问任何人 ## 3. 常见问题表现 - 浏览器能访问 Google - Node 请求外网超时 - 某些桌面应用无法连接 - curl 命令无法访问被限制网站 # 五、TUN 模式详解 ## 1. TUN 模式原理 一句话理解 TUN：TUN = 在操作系统底层插入一张虚拟网卡。 ## 2. 工作机制 开启 TUN 后，所有网络流量的流向变为： 所有程序 → 操作系统 → 虚拟网卡（TUN） → Clash → 节点/直连 ### 受影响的程序类型 开启 TUN 后，以下程序都无法绕过代理： - 浏览器 - Node 程序 - 桌面应用 - Docker 容器 - curl 等命令行工具 **核心特点**：没有任何程序可以说"我不想走代理"。 ## 3. TUN 模式的优势 ### 正面效果 - Node、App、命令行突然都能翻墙了 - 无需逐个配置程序的代理设置 - 全局流量统一管理 ## 4. TUN 模式的副作用 ### 常见问题 - 原本能访问的内网服务失效 - localhost 或局域网访问异常 - 上传/下载偶发卡死 - 网络行为变得"不可预测" ### 根本原因 TUN 模式在 IP 层拦截流量，可能导致以下问题： 1. 内网服务流量被错误路由到代理 2. 本地服务请求被转发到外部节点 3. 某些应用的网络检测机制失效 **结论**：TUN 很强，但副作用也最大。 # 六、Clash 模式选择 ## 1. 规则（Rule）模式 ### 工作方式 按照预设的规则来决定流量走向。 ### 典型规则配置 - 国外网站 → 走代理 - 国内网站 → 直连 - 局域网地址 → 直连 ### 推荐场景 这是最推荐、最理性的模式，适合长期使用。 ## 2. 全局（Global）模式 ### 工作方式 不管访问什么，全部走代理。 ### 适用场景 - 临时排查问题 - 确认"是不是网络导致的" ### 不推荐场景 不适合长期使用，会影响访问速度和稳定性。 ## 3. 直连（Direct）模式 ### 工作方式 完全不走代理。 ### 理解方式 可以理解为"我现在不用梯子了"。 # 七、模式选择指南 ## 1. 核心原则 记住以下几句话即可： **系统代理**： - 浏览器愿意听 - 别人不一定听 **TUN 模式**： - 谁都得听 **模式对比**： | 特性 | 不开 TUN | 开 TUN | |------|---------|--------| | 稳定性 | 高 | 低 | | 可控性 | 高 | 低 | | 适用场景 | 开发环境 | 临时需要 | | 副作用 | 小 | 大 | **模式选择**： | 模式 | 适用性 | |------|--------| | 规则模式 | 长期最优解 | | 全局模式 | 临时排查 | | 直连模式 | 不使用代理 | # 八、常见问题排查 ## 1. 问题分类思路 网络问题不是玄学，关键在于知道"控制权在哪一层"： ### 第一层：浏览器决定 - 问题表现：仅特定浏览器无法访问 - 排查方向：浏览器代理设置 ### 第二层：系统决定 - 问题表现：所有浏览器一致，其他程序不受影响 - 排查方向：系统代理配置 ### 第三层：IP 层决定 - 问题表现：所有程序网络行为异常 - 排查方向：TUN 模式配置 ## 2. 调试建议 ### 确认问题范围 1. 测试浏览器访问 2. 测试命令行工具（curl） 3. 测试本地服务（localhost） ### 逐步排查 1. 先关闭 TUN，确认是否为 TUN 导致 2. 切换到规则模式，检查规则配置 3. 使用全局模式测试，确认代理本身是否可用 ## 3. 开发环境建议 ### 推荐配置 - 开发时使用系统代理 + 规则模式 - 避免开启 TUN，除非明确需要 - 为开发工具配置直连规则 ### 常见开发工具直连建议 - localhost/127.0.0.1 - 局域网 IP 段（如 192.168.x.x） - Docker 网桥 - 本地数据库端口 # 九、总结 ## 1. 核心要点 以前觉得网络问题是玄学，现在发现：不是玄学，是我们不知道"控制权在哪一层"。 一旦你知道： - 是浏览器在决定 - 是系统在决定 - 还是 IP 层在决定 很多"莫名其妙的问题"，都会变成可解释、可定位、可解决的问题。 ## 2. 快速参考 | 模式 | 特点 | 适用场景 | |------|------|---------| | 系统代理 | 稳定、可控 | 日常开发 | | TUN 模式 | 强制、副作用大 | 特殊需求 | | 规则模式 | 智能、灵活 | 长期使用 | | 全局模式 | 简单、粗暴 | 临时测试 | *** ## 参考资料 1. [一次把「代理 / 节点 / TUN / Clash 模式」讲明白](https://mp.weixin.qq.com/s/ZvvjuPC6nuFy-z8LLr0yrQ) 最后修改：2026 年 01 月 17 日 © 允许规范转载 赞 如果觉得我的文章对你有用，请随意赞赏