简介 Link to heading
本文作为上篇，主要是介绍一些相关知识，下篇负责实际操作的内容。
什么是透明代理 Link to heading
根据代理（proxy）的位置，我们将代理分为前向代理（Forward Proxy）和反向代理（Reverse Proxy）两大类：
- 前向代理：运行在 client 一侧，代替 client 向 server 发送请求，例如我们日常使用的科学上网代理客户端，如 clash verge；
- 反向代理：代替服务端接受互联网或者外部请求，然后将请求路由到对应的服务端，caddy 就有 reverse_proxy 功能；
根据代理对于 client 或者 server 是否可见（visible），还可以将代理划分为透明代理（TProxy）与非透明代理两类：
- 非透明代理：客户端需要修改目的地址为代理服务器的地址，并使用代理协议连接代理服务器；
- 透明代理：所谓透明代理，即客户端和服务端感知不到代理的存在，客户端无需修改目的地址，也不需要采用代理协议连接代理服务器，所有目的地址转换都是在透明代理中完成的；
Fake IP 的 DNS 解析流程 Link to heading
当前，Clash 的 DNS 解析基本都已放弃 redir-host 模式，转而采用 Fake IP 模式；
我们用一个例子说明 Fake IP 的 DNS 解析流程：假设 Mac 执行 curl qq.com，那么第一步，Mac 要先进行 DNS 查询，我们在 Clash.Meta 的 rules 部分写的规则，就是用来匹配这个 DNS 查询的。
-
假设命中了
DOMAIN-SUFFIX,qq.com,PROXY，那么 Fake IP 网关（这里指 Clash.Meta）会返回一个 Fake IP，例如192.18.1.1，这个 IP 当然不是 qq.com 对应的真正的 IP；- Mac 对这个 Fake IP 建立连接，并发送出去；
- 代理客户端捕获这个连接，从连接中拿到 Mac 要与之建立连接的 Fake IP，然后查询得到该 Fake IP 对应的域名；
- 将连接基于 socks5 或者某种协议重新封装（封装的信息包含了要访问的域名），发送到代理服务器，由代理服务器进行真正的 DNS 解析；
-
假设命中了
DOMAIN-SUFFIX,qq.com,DIRECT，那么 Fake IP 网关（这里指 Clash.Meta）会返回一个 mihomo，例如192.18.1.2，这个 IP 当然不是 qq.com 对应的真正的 IP；- Mac 对这个 Fake IP 建立连接，并发送出去；
- 代理客户端捕获这个连接，从连接中拿到 Mac 要与之建立连接的 IP，然后查询得到该 IP 对应的域名；
- 代理客户端（Clash.Meta）使用配置文件中指定的 DNS 对域名进行解析，返回真实的 IP，例如
2.2.2.2； - Mac 与
2.2.2.2建立连接，传输数据；
假设 Clash.Meta 的 rules 中有基于 IP 分流的规则，Clash.Meta 匹配分流规则与 DNS 查询时，是从上往下依次检查规则是否匹配的，假设检查到了基于 IP 分流的规则，那么 Clash.Meta 需要使用配置文件中指定的 DNS 进行 DNS 查询；
因此，Fake IP 模式下会出现 DNS 泄漏的情况只有两种：
- 域名匹配到直连规则（那么运营商知道我们访问可以直连的网站，无所谓）；
- 检查 DNS 查询与基于 IP 分流的规则是否匹配，这里的解决方案是，对于 IP 分流的规则，该规则后面都加上
no-resolve
我的匹配规则如下，no-resolve 表示在检查规则是否匹配时，不进行 DNS 解析，即只有 Mac 想要直接通过 IP 而不通过域名建立连接时，才会匹配到这条规则。
rules:
# 开始匹配规则
- RULE-SET,mdirect,国内
- RULE-SET,mproxy,其他
- RULE-SET,direct,国内
- RULE-SET,cncidr,国内,no-resolve
- RULE-SET,private,国内
- RULE-SET,mdirect-ip,国内,no-resolve
- RULE-SET,apple-direct,国内
- RULE-SET,lancidr,国内,no-resolve
- RULE-SET,applications,国内
## GEOSITE
- GEOSITE,bilibili,国内
- GEOSITE,icloud,icloud
- GEOSITE,apple,apple
- GEOSITE,onedrive,onedrive
- GEOSITE,spotify,spotify
- GEOSITE,youtube,youtube
- GEOSITE,netflix,stream
- GEOSITE,google,google
- GEOSITE,telegram,telegram
- GEOSITE,github,github
- GEOSITE,microsoft,microsoft
- GEOSITE,steam@cn,国内
- GEOSITE,openai,openai
- GEOSITE,category-games@cn,国内
- GEOSITE,geolocation-!cn,其他
- GEOSITE,cn,国内
- RULE-SET,telegramcidr,telegram,no-resolve
- RULE-SET,gfw,国内
# 是否有这样的请求，域名不在上述规则之内，但是 ip 又是国内的？目前看来，似乎没有碰到过这样的情况；故选择 GEOIP,CN,DIRECT,no-resolve
- GEOIP,cn,国内,no-resolve
- MATCH,其他
Clash.Meta 的 DNS 解析流程如下：
透明代理的工作流程 Link to heading
客户端，以 Mac 为例，Mac 无需任何的设置，直接以 DHCP 的方式连接到路由器的 WIFI 即可。
主路由则是需要设置 Dnsmasq，将客户端的 DNS 请求，都转发给运行在 N1 的 mosdns：
- mosdns 对于国内域名的 DNS 请求，直接进行 DNS 解析，将解析结果（IP）返回给 Mac，Mac 将与这个 IP 建立连接，从此该连接的流量直接从主路由出站；
- 对于国外域名的 DNS 请求，mosdns 会再将 DNS 请求转发给 TPClash；
TPClash 会返回一个 Fake IP（192.18.x.x），Mac 会尝试与 Fake IP 建立连接，流量会流向这个 Fake IP，路由器需要设置静态路由，将 Fake IP 连接对应的流量路由给 Fake IP 网关，即 N1 上的 TPClash。TPClash 捕获这个连接，从连接中拿到 Mac 要与之建立连接的 Fake IP，然后查询得到该 Fake IP 对应的域名；将连接基于 socks5 或者某种协议重新封装（封装的信息包含了要访问的域名），发送到代理服务器，由代理服务器进行真正的 DNS 解析，并与目标 IP 建立连接。
这样，Mac 就能正常访问谷歌了。
Fake IP 网关的工作流程如下所示：
从流程上来说，可以直接通过 Dnsmasq 将 DNS 请求转发给 TPClash，即 192.168.6.206#1053，这样就有一个问题：
-
所有的流量都会经过 TPClash，再从主路由出站，等同于 Mac 直接设置静态 IP，将网关设置为 N1；
-
Fake IP 机制会导致即使访问国内的域名，也会发生两次 DNS 解析，第一次是直接返回 Fake IP，与 Fake IP 建立连接后，第二次由 Fake IP 反查出域名，再通过 Clash 配置文件中设置的 DNS 服务器进行真正的 DNS 解析；
将 DNS 请求经 mosdns 中转，功能类似于 fake-ip-filter，通过设置 mosdns 的规则，可以保证国内域名都直接解析而不经过 TPClash 的 DNS 解析，从而访问国内域名的流量，除了第一次 DNS 请求解析之外，不需要再经过 TPClash。
而 fake-ip-filter 只能自己在配置文件中输入所有的直连域名，mosdns 则可以从本地 txt 文件中读取域名列表，因此我们可以利用 Loyalsoldier 的 v2ray-rules-dat（这位大佬的这个仓库，每两天会更新国内域名列表以及可直连域名列表的 txt 文件）。
N1 的 IP 为 192.168.6.206，TPClash 的 DNS 监听端口为
0.0.0.0:1053；
mosdns 与主路由的配置，由于篇幅原因，请见 利用 mosdns 与 TPClash 搭建透明代理（下）