不嗅探
转发层不介入 TLS 握手，也不持有任何解密密钥。 HTTPS 请求在它看来是一串无法解读的字节流，它只能看到这些字节从哪个目标地址发出、要送到哪里去。 想解析内容，需要的不是「意愿」而是「能力」——而它并不具备这种能力。
流量转发透明 · 不嗅探不篡改 · 传输路径自主可控
它负责送，
它负责送，
但不负责看，也不改动
Clash 是一个转发层。它决定连接的目标该走哪条路径， 然后按规则把它交给对应出口——但不去解析应用层的内容，不改写请求与响应，也不在流量里加任何东西。 HTTPS 对它来说始终是不透明的负载。中转节点由你自行选定，官方不介入链路，也无从获取链路内容。
不解析内容不修改请求不植入代码
无中间人路由自主本地判断
0对应用层内容的解析动作
0对请求与响应的改写次数
0植入流量中的追踪代码
本地判断过程全程在设备上完成
Data Path
一段流量的完整旅程
把请求从设备发出到抵达目标的过程摊开来看。中间那一段是 Clash 的位置， 它的职责范围到此为止——再往里的事情，它看不见，也管不着。
◉
应用发起请求
浏览器、开发工具、系统服务——发起连接的那一端
→
⌘
Clash 转发层
只看目标地址与规则，不看内容，不改载荷
→
⇄
你选定的出口
直连、自建节点或订阅线路——由你自己决定
它知道的：目标地址、端口、命中的规则、使用的策略组
它不知道的：请求体、响应体、TLS 之后的所有内容
它不参与：密钥交换、证书验证、应用层协议解析
i
转发层的职责边界很清楚。它需要知道「这个连接要去哪儿」，才能决定怎么送； 但它不需要知道「这个连接里放了什么」，也不需要改动里面的任何东西。判断依据和目标内容，是两件不同的事。
Visibility
它看得见什么，看不见什么
用「网络层级」的方式对照，能更清楚地说明转发层处在哪个位置，以及它的可见范围到哪里为止。
| 层级 | 内容 | 转发层是否可见 |
|---|---|---|
| 连接目标 | 目标域名、IP 地址、端口号 | 必须可见，这是判断依据 |
| 传输层元信息 | 协议类型、连接状态、字节量 | 可见，用于统计与调度 |
| TLS 握手 | 加密套件、证书链、密钥交换过程 | 不介入，也不握持密钥 |
| 应用层载荷 | HTTP 请求体、响应内容、页面数据 | 不可见，视为不透明字节流 |
| 加密通信内容 | HTTPS、SSH、各类加密协议的明文 | 不可见，没有解密能力 |
| 身份与凭据 | 账号、密码、令牌、Cookie 内容 | 不可见，无从获取 |
它需要知道去哪儿，
但不需要知道带了什么
但不需要知道带了什么
这是转发层与「中间人」的本质区别：前者只负责路径，后者会介入内容。 Clash 属于前者，且仅属于前者。
Three Commitments
不嗅探、不篡改、不介入
这三件事不是「尽量不做」，而是结构上做不到。下面分别说明为什么。
不篡改
不改写请求头，不替换响应内容，不注入脚本，也不插入广告。 规则决定的只是「这个连接走哪条路」，与「这个连接里放了什么」完全无关。 转发层只搬运数据包，不做内容层面的任何加工。
不介入链路
中转节点由你自行选定，项目方不提供节点、不参与链路、也无从获取其中的内容。 你与出口之间的通信由你选择的协议保护，出口与目标站点之间的那一段， 取决于你使用的协议与目标站点的加密情况——Clash 既不介入，也不知晓。
What It Does
它做什么，不做什么
把转发层的工作范围摊开来看，边界会更清楚。
✓
转发层负责的事
- 判断目标：读取连接的目标地址、端口，判断它属于哪一类
- 匹配规则：按配置文件中的规则顺序逐条比对，命中即执行
- 选择出口：把连接交给对应策略组，由策略组决定用哪条线路
- 转发数据：按确定好的路径把数据包送出去，不查看也不改动内容
- 记录状态：在本地记录连接数量、延迟等信息，用于展示与调度
✕
转发层不做的事
- 不解析内容：不尝试解读应用层协议，不还原请求与响应
- 不改写数据：不修改请求头、响应体，不替换任何字段
- 不植入代码：不加追踪标识，不插入广告，不注入脚本
- 不持有密钥：不参与 TLS 握手，无解密能力
- 不上报数据：不向项目方传输连接目标或访问记录
!
需要区分「转发层」与「出口」。转发层不做内容层面的任何事， 但你选择的出口与目标站点之间的链路，取决于你使用的协议。 如果使用加密协议，那一段是加密的；如果是明文协议，则并非如此。这一点由你的选择决定，而不是由转发层决定。
Your Route
路径由你定义，不由别人安排
传输路径不是固定的，也不是由项目方预设的。规则怎么写、出口怎么选， 最终决定了数据走哪条路——而这个决定权在使用者手上。
01
直连还是绕行，规则说了算
同一条规则可以指向 DIRECT、PROXY、REJECT 或某个策略组。
哪些目标就近发出、哪些交给代理、哪些直接拦下，全部写在配置文件里，肉眼可查。
02
出口由你选择，不预设也不推荐
项目不提供节点，不推荐线路，也不限制使用哪家服务。 策略组里有哪些出口、这些出口从哪来，完全取决于你自己引入的订阅或自建配置。
03
可以指定加密通道，避开不明中转
如果你对路径的隐私性有更高要求，可以在策略组中只选用加密协议的节点， 或在规则里把敏感目标直接指向受信任的出口，避免经过来源不明的中转。
04
连接记录在本地，不对外发送
客户端面板会展示当前经过的请求与命中的规则，但这些信息只保留在你的设备上。 是否导出、是否留存、是否清理，都由你自己决定。
05
配置自持，路径可随时复查
规则与策略组都是纯文本，可以随时打开确认某个目标会走哪条路。 改动前导出备份，改动后重新载入，整个过程都在你的控制范围内。
自主可控不是一句口号，而是一组可以核对的事实：
规则是自己写的，出口是自己选的，配置是自己保管的，连接记录只留在本地。
这四件事合在一起，才构成「清楚数据走向」的完整含义。
Not a MITM
转发层与中间人，差在哪里
「中间人」这个词经常被和「中转」混为一谈，但两者在做的事完全不同。 下面这张对照表把区别摊开来看。
| 对比维度 | 普通转发层 | 中间人 |
|---|---|---|
| 对内容的态度 | 只搬运，不解读 | 解密、读取、可改写 |
| 是否介入 TLS | 不介入，透传加密流量 | 介入握手，持有证书与密钥 |
| 是否改动载荷 | 不修改任何字节 | 可替换内容、注入脚本 |
| 路径决定权 | 使用者通过规则定义 | 由中间人自行安排 |
| 对使用者的透明度 | 路径与规则可见可查 | 过程对使用者不透明 |
i
「中间人」的核心特征是介入内容。它需要解密才能看到明文， 需要持有证书才能冒充目标站点，需要改写载荷才能插入内容。 转发层不具备其中任何一项能力，也不尝试获取——这是结构上的区别，不是承诺上的区别。
Rule Example
规则描述的是路径，不是内容
配置文件里的每一条规则，只回答「这个目标走哪条路」，不涉及任何内容层面的判断。 下面这份片段可以说明这一点。
# 规则只关心「去向」，不关心「内容」
rules:
# 本地开发环境直连
- DOMAIN-SUFFIX,internal.dev,DIRECT
# 广告域名就地拦截
- DOMAIN-KEYWORD,ads,REJECT
# 私有网段不绕行
- IP-CIDR,10.0.0.0/8,DIRECT,no-resolve
# 需要绕行的目标交给策略组
- DOMAIN-SUFFIX,example.com,PROXY
# 兜底
- MATCH,PROXY
Read the Rules
每一条都在说「去哪」，没有一条在说「是什么」
DOMAIN-SUFFIX
匹配的是域名后缀，
IP-CIDR
匹配的是网段。它们都不读取请求体，也不解析响应。
规则的动作是 DIRECT、PROXY、 REJECT 或某个策略组名——全部都是路径层面的指令。 没有一条规则能表达「如果内容里出现某个词就怎样」，因为转发层根本没有这个能力。
i
规则的表达能力，恰好映射了转发层的能力边界。 它能写出来的，就是它能做到的；它做不到的，也写不出来。
Scenarios
这些场景里，透明意味着什么
抽象的原则落到具体场景，会更容易理解它带来的实际差异。
◐
处理敏感信息时
登录银行、企业后台、内网系统——这些连接的内容对转发层不可见。 它只看到「这个连接要去某个域名」，但不知道你提交了什么、返回了什么。
◑
开发调试时
本地服务、测试接口、线上环境同时开着。规则把流量分到不同路径， 但不会因为「需要调试」就去读取接口的请求体或响应内容。
◒
在意链路来源时
如果你只信任特定地区的节点，可以在策略组中只选用那些出口。 规则指向哪个组、组里有哪些节点，全部由你自己编排。
◓
排查流量走向时
打开连接记录面板，能看到每个请求命中了哪条规则、走了哪个策略组。 这些信息在本地可查，用来确认路径是否符合预期。
◔
需要保留证据时
连接记录完全在你自己的设备上。是否导出、保留多久、要不要清理， 都由你决定，不依赖任何外部服务。
◕
不希望被额外收集时
项目不强制上报，客户端不向项目方传输访问记录或连接目标。 你选择引入的订阅或规则集来自何处，那部分由对应来源决定——这一点需要你自己确认。
Boundaries
把边界讲清楚，比说「绝对安全」更有用
下面几件事需要说明白。透明的意义在于准确，而不是让人产生过高的期待。
◐
转发层不等于全程加密
转发层不介入内容，但加密与否取决于你使用的协议与目标站点。 访问明文 HTTP 站点时，链路上的那一端仍然可能看到内容——这不是转发层能改变的。
◑
出口的安全取决于你的选择
项目不提供节点，也不为任何节点的行为背书。 出口是否可信、链路是否加密、运营方是否记录日志，都需要你自行判断。
◒
连接目标本身是可见的
为了判断路径，转发层需要知道目标地址。这一点无法回避—— 判断的前提就是知道「要去哪儿」。它不看内容，但知道目标。
!
「不窥探内容」与「完全不可见」是两件事。 转发层不解析应用层内容，也不改动任何数据；但它确实需要读取连接的目标地址来完成判断。 这种可见性是判断的前提，也是它与「中间人」最根本的区别——前者只看信封上的地址，后者会拆开信封。
Q & A
关于流量透明，常被问到的几件事
Clash 会看到我的 HTTPS 内容吗？
看不到。Clash 只处理连接的目标地址与转发路径，不介入 TLS 握手，也没有握持任何解密密钥。HTTPS、SSH、各类加密协议的内容对它来说都是不透明的负载，它只负责把它们送到正确的出口。
会不会在请求里插入广告或追踪代码？
不会。转发层不修改应用层载荷，既不改写请求体，也不注入响应内容。规则决定的只是「这个连接走哪条路」，而不是「这个连接里放了什么」。
中间的节点能看到我的数据吗？
节点由你自行选择。如果使用加密协议，节点与你之间的通信是加密的；至于目标站点与节点之间的那一段，取决于你使用的协议与目标站点的加密情况。Clash 不介入选择，也不参与链路。
官方会记录我的访问日志吗？
不会。转发判断全部在本机完成，客户端不向项目方上报连接目标、访问记录或流量内容。连接记录只保留在你自己的设备上，是否导出、是否留存由你决定。
怎么确认我的流量真的走了预期的路径？
可以在客户端的连接记录面板查看每个请求命中的规则、使用的策略组与出口。规则是自己写的，策略组是自己配的，出口是自己选的——三段路径都在本地可见。
规则里写 REJECT 会看到被拦截的内容吗？
不会。拦截发生在连接建立阶段，请求根本没有发出。客户端只知道「这个目标被规则拦下了」，并不知道你原本打算访问的具体内容。
Next
想继续了解，可以看这几页
这一页讲的是转发层的透明性。相关的话题分散在下面几页里。
◫
想了解项目的整体立场
去「项目介绍」页。那里说明了项目坚持什么、拒绝什么， 以及为什么强调「全本地运行」和「不替用户做选择」。
✎
想看清规则怎么写
去「分流规则」页。规则的表达能力与转发层的能力边界是对应的， 看懂规则，也就看懂了它能做什么、不能做什么。
⇅
想确认授权与分发边界
去「开源许可」页。那里说明了使用、修改与分发的条款， 以及免责范围与版权归属。
◎
想找规则集与工具资源
去「社区生态」页。规则集、订阅模板、插件脚本、界面面板， 以及怎么判断一份资源是否还在维护，都整理好了。
透明的意义在于准确。不夸大能力，也不回避边界——
转发层只做路径判断，不介入内容；目标地址可见，应用载荷不可见；路径由你定义，记录留在本地。
把这几件事说清楚，比笼统地承诺「绝对安全」更有价值。