[Feature] 能否在 Wiki 加上 "实验性：绕过中国大陆 IP" 具体实现的流程图

[gemnioo]

Verify Steps

• Tracker 我已经在 Issue Tracker 中找过我要提出的问题
• Need 当前 OpenClash 并不包含该功能特性或者还不完善
• Framework 这是 OpenClash 应包含的特性, 并非 Clash 特性
• Meaningful 我提交的不是无意义的 催促更新或修复 请求

Describe the Feature

折腾了一周 OpenClash, 建议 Wiki 区画一张类似 Clash.Meta 的 DNS 解析流程图

搜索遇到很多的问题，为了配合更复杂的 SmartDNS/MosDNS； AdGuardHome 等等会涉及到关于 DNS 分流这部分的解析路径问题，方便使用者理解

已知：

1. Clash 的 DNS和代理两个模块是独立的. 日常终端PC使用 Clash for Windows 开启Systerm Proxy( HTTPS/SOCKS5代理) 并不需要 DNS enable: true, TUN 模式 是虚拟了网卡, 接管一切流量. OpenClash 实现虚拟网关用的是 TUN 模式, 而 Fake-IP /Redir-Host 的TUN模式、游戏模式 是(TAP 模式 很绕口 而 TAP 模式更推荐使用 Redir-Host 模式
2. OpenClash 的绕过大陆IP 主要由两个模块组成 . 使用一份国内站点域名表 2w多条，添加至 Dnsmasq 中，在这个域名表中的 将会使用 默认114.114.114.114 来进行解析为真实的 IP ，在 iptables 中添加中国大陆 IP 段（ ipset ；直接绕过的规则并不使用 Clash 核心的 DNS 解析. 由此解决了 所有流量都经 Clash 核心转发，性能损耗过大 的问题
3. 插件设置-DNS设置中 *本地 DNS 劫持 使用防火墙转发 才能有黑白名单不走代理的局域网IP/MAC 选项. 我不清楚为何Redir-Host 模式 两种转发都能选黑白名单. Fake-IP 模式只在使用防火墙转发才能选择黑白名单. issue区有两种方法 [Feature] fakeIP模式下访问控制也有“不走代理的局域网设备 IP” #2506 [Feature] Fake-IP模式下对于MAC/IP黑白名单、绕过大陆IP，可否提供更多选项？ #3319 也有回复说 绕过中国大陆 IP 的实现是靠 Dnsmasq 先 DNS 分流判断实现的, 选择使用防火墙转发会使此功能失效
4. 上游 Clash 官方已弃用 Redir-Host (redir-host mode no longer available from Premium 2023.02.16) Clash.Meta 还在使用两者; Clash for Windows 不换核情况下 遵循上游 Clash 默认TUN Mode 是Fake IP Mode ; 两者的区别只是 Fake-IP-filter: - '+.*' 绕过所有域名 就变成 Redir-Host Mode
5. Fake-IP 模式 用假IP映射是为了使用 Rule 域名规则, 需要代理域名的解析均传递真实域名到代理服务器上 所以并无必要获得无污染DNS的解析 IP. Clash.Meta 的嗅探功能是为了把 Redir-Host 模式的 “真实IP” 变回域名. (实现CDN优化 解锁Netflix 等. 所以 Fake-IP 模式只需要配置 nameserver 并无必要配置 fallback 以及 fallback filter ; 配置nameserver 仅为了直连和fakeip filter 内的国内加速.

Describe the Solution

目前遇到以下问题的解法 均未使用 Meta 内核

开启Fake-IP模式 选择绕过大陆IP 选择Dnsmasq转发 希望终端设备 .2.12 不走代理.

1. 日志大量DNS请求报错
   Config内配置 - SRC-IP-CIDR,192.168.2.12/32,DIRECT 实现本机不走代理. 此种情况下 流量依旧入站 OpenClash 核心, 日志观察到的是 类似 proxy=DIRECT lAddr=192.168.2.21:6109 rule=SrcIPCIDR rulePayload=192.168.2.21/32 出现大量 WRN [TCP] dial failed error 日志 大量 报错 WRN [TCP] dial failed error #3454 的原因是 终端PC CFW 配置了
   fallback:

   • https://1.1.1.1/dns-query
   • https://dns.google/dns-query
     因此时是 DIRECT 所以国外的DNS间歇性被墙 终端PC删掉 fallback 就可以

2. 终端 CFW无法使用代理
   因为梯子提供商提供的是国内域名 类似 xx.xxx.xyz 并不在 添加在 Dnsmasq 2w多条域名列表中, 所以入站 OpenClash 核心, 按规则一条条往下 直到 Geo-IP, Direct Match, Proxy 得到的是 Fake-IP 映射假IP ！最终使用海外落地节点解析. 流量回环！ 所以连不上；
   添加 梯子提供商订阅内的几个域名( 国内入口) 到 fake-ip-filter: 中 或者写规则 - DOMAIN, xx.xxx.xyz, Direct 可以使终端使用CFW代理 OpenClash logs 内显示的是 proxy=DIRECT lAddr=192.168.2.21:61095 rAddr= xxx.xx.xyz:443 rule=SrcIPCIDR rulePayload=192.168.2.21/32

3. 苹果设备待机耗电量 [Bug] R2S 旁路由运行 OpenClash 严重增加局域网内 iPhone 待机耗电 #2614
   查看 logs 请求 均是 类似 数字+courier.push.apple.com:5223 的请求, 匹配了 Rule -DOMAIN-SUFFIX, apple.com, Apple(Direct) 但被国内 DNS 解析到海外IP. 在苹果规则 Rule-Set 之上 添加一条 DOMAIN-SUFFIX, courier.push.apple.com，Proxy 歪打正着

Describe Alternatives

按照 OpenClash 的绕过大陆IP 的实现是先匹配添加至 Dnsmasq 中的国内站点域名表 2w多条，在这个域名表中的使用 默认114.114.114.114 来进行解析为真实的 IP ，再匹配写入 iptables 中添加中国大陆 IP 段. 无法匹配才入站 OpenClash (Google Facebook Twitter等 不匹配域名表直接入站；caixin 在列表中，但可能会被 114 解析成海外IP，无法匹配也会入站.

1, 既然已经匹配过一次筛选出需要代理的绝大部分域名DNS请求 还需要配置nameserver 参数么？ 在 iptables 中添加中国大陆 IP 段其实就是 GeoIP, Direct 规则匹配的 区别是前者Dnsmasq 中根据域名分类DNS请求， 后者匹配不成功域名规则才向 nameserver 查询DNS请求来配对GeoIP 规则. 我不清楚苹果的某些域名在不在那 两万多列表内. 按某些情况下 需要Apple规则都走代理. 是需要入站到 OpenClash内再次选择的 方便添加规则 譬如 courier.push.apple.com 走代理 ；或者解决 某些PodCast 即使美区依旧无法搜索到内容的情况

2, 被默认 114解析到海外IP的情况 譬如 caixin.com 在Dnsmasq 域名表内, 但有很大几率查询到海外IP，OpenClash 可配置 nameserver-policy: '+.caixin.com': '61.132.163.68' 解决默认 nameserver 不友好的情况

3, 国内小众域名譬如 ddys.art ；梯子商的国内入口. 走 OpenClash 不匹配规则需要 Match, Direct/Proxy 之间调试

4, Clash 的规则分流广告已经很好了 没必要在去折腾 去广告 AdguardHome (反而更慢 ，用AdGuardHome 的 Web 管理页面轻松实现内网设备是否走代理倒是有意义的

5, SmartDNS/MosDNS 国外域名并发加速/缓存 只对Redir-Host模式有意义

Additional Context

折腾一周多 OpenClash 查询到的有帮助的内容. 没有 Blog 发到这里吧， 发现很多配置教程都人云亦云

1， YouTuber 不良林 关于 DNS 泄露的三+一期视频 以及UDP那期

2，关于旁路网关设置透明代理的种种问题 旁路由的原理与配置一文通 关于旁路由设置后，主路由WIFI无法上网的问题

3，Sukka 大佬写的 浅谈在代理环境中的 DNS 解析行为 我有特别的 DNS 配置和使用技巧

[tigerdoo]

所以如果DNS设置是禁用“本地DNS劫持”的话，绕过大陆IP的选项就是不生效的是吗？

[gemnioo]

是的 绕过大陆IP 就是劫持本地 DNS先做一次分流

日志启动后 有这样一条 ”在 FAKE-IP 模式下绕过中国 IP 可能会导致 Dnsmasq 加载时间过长，暂时劫持 DNS 至内核直到 Dnsmasq 正常工作“

[yyysuo]

楼主说得非常好，绕过大陆ip这个功能，dnsmasq分流一次，进入clash内核再分流一次，造成了很多问题，我反正觉得是没有必要，目前是meta+fakeip+tun+停用dns劫持+关闭绕过大陆，体验非常好。

[tigerdoo]

我开启meta内核后，adguardhome日志里客户端全都是127.0.0.1

[gemnioo]

楼主说得非常好，绕过大陆ip这个功能，dnsmasq分流一次，进入clash内核再分流一次，造成了很多问题，我反正觉得是没有必要，目前是meta+fakeip+tun+停用dns劫持+关闭绕过大陆，体验非常好。

绕过大陆IP是为了分流！！ 减少Clash Core 占用. 很多人用AdGuardHome 或者 SmartDNS/MosDNS 前置分流也是一个道理 谁是谁的上游 DNS为了无污染解析还是分流

所以希望 wiki 画张 类似 Clash Meta 的图 *红字的功能和实验性用不了 更加搞不懂

[refined-fish]

楼主说得非常好，绕过大陆ip这个功能，dnsmasq分流一次，进入clash内核再分流一次，造成了很多问题，我反正觉得是没有必要，目前是meta+fakeip+tun+停用dns劫持+关闭绕过大陆，体验非常好。

绕过大陆IP是为了分流！！ 减少Clash Core 占用. 很多人用AdGuardHome 或者 SmartDNS/MosDNS 前置分流也是一个道理 谁是谁的上游 DNS为了无污染解析还是分流

所以希望 wiki 画张 类似 Clash Meta 的图 *红字的功能和实验性用不了 更加搞不懂

同求，另外能否请教一个问题，如果使用mosDNS前置分流，是否是指mosDNS转发非大陆请求到openclash？这是不是会导致openclash仅接到IP请求，从而openclash只能IP规则分流（域名已经被mosDNS用掉了）域名规则失效？

[gemnioo]

同求，另外能否请教一个问题，如果使用mosDNS前置分流，是否是指mosDNS转发非大陆请求到openclash？这是不是会导致openclash仅接到IP请求，从而 OpenClash只能IP规则分流（域名已经被mosDNS用掉了）域名规则失效？

还没有折腾过 MosDNS 是转发器 根据域名和IP表分流 https://songchenwen.com/tproxy-split-by-dns 如图 fallback 才用到DNS服务器解析成 IP 分流.

「 插件设置 - GEO 数据库订阅 把 GeoIP Dat 和 GeoSite 这两个库的自动更新打开，都选 Loyalsoldier 的版本，这个是用来给 mosdns 用的。
这里 mosdns 监听了 5335 端口。并且要在 GeoData 数据导出 里配置上我们用到的标签：GeoSite: cn, apple-cn, category-games@cn, geolocation-!cn, GeoIP: cn」

OpenClash 的绕过大陆IP 只有域名规则命中才走114解析 不属于大陆IP段的和不在域名规则的才入站 Clash 核. 应该问在域名规则中 但被114解析到国外IP 入站 Clash 是域名还是IP 我猜是 IP

[refined-fish]

同求，另外能否请教一个问题，如果使用mosDNS前置分流，是否是指mosDNS转发非大陆请求到openclash？这是不是会导致openclash仅接到IP请求，从而 OpenClash只能IP规则分流（域名已经被mosDNS用掉了）域名规则失效？

还没有折腾过 MosDNS 是转发器 根据域名和IP表分流 https://songchenwen.com/tproxy-split-by-dns 如图 fallback 才用到DNS服务器解析成 IP 分流.

「 插件设置 - GEO 数据库订阅 把 GeoIP Dat 和 GeoSite 这两个库的自动更新打开，都选 Loyalsoldier 的版本，这个是用来给 mosdns 用的。 这里 mosdns 监听了 5335 端口。并且要在 GeoData 数据导出 里配置上我们用到的标签：GeoSite: cn, apple-cn, category-games@cn, geolocation-!cn, GeoIP: cn」

OpenClash 的绕过大陆IP 只有域名规则命中才走114解析 不属于大陆IP段的和不在域名规则的才入站 Clash 核. 应该问在域名规则中 但被114解析到国外IP 入站 Clash 是域名还是IP 我猜是 IP

很不错的文章，我准备试试这个方案，我不需要AD，我就直接转发到MosDNS，分流后给clash，我已经很长时间使用了单独的clash，实在是无法满意，如果不开绕过IP，那么性能开销是一回事，还会把所有的流量都计算在旁路由头上，流量统计和QOS失效，如果开启绕过大陆，又会导致一些域名/IP没有被正确代理

[kingsey]

楼主说得非常好，绕过大陆ip这个功能，dnsmasq分流一次，进入clash内核再分流一次，造成了很多问题，我反正觉得是没有必要，目前是meta+fakeip+tun+停用dns劫持+关闭绕过大陆，体验非常好。

开绕过大陆只为了性能开销，我的辣鸡设备关了绕过就跑不满千兆了

[gemnioo]

更新到 v0.45.141-beta Fake IP 增强模式 使用防火墙转发 黑白名单添加 不走代理的局域网设备 IP/MAC 192.168.2.21 macOS 192.168.2.10 Windows

后台查看日志如上两台设备还是进了内核 断电重启主路由 旁路网关后，日志内只会出该.2.21 macOS 有如下地址 WRN [TCP] dial failed error=dial 的请求

其中

2023-09-18 14:03:45 INF [UDP] connected lAddr=192.168.2.21:49838 rAddr=time.g.aaplimg.com:3478 mode=rule rule=SrcIPCIDR(192.168.2.21/32) proxy=DIRECT

Config 加了 - SRC-IP-CIDR,192.168.2.10/32,DIRECT - SRC-IP-CIDR,192.168.2.21/32,DIRECT 是为了保底

查询是 DNS TXT record 不知道Windows 设备为何也会有这个请求 ，黑白名单不走代理 等于添加了 iptable 规则分流。 观察日志仅有这条UDP请求进入到Clash

目前注释掉 - SRC-IP-CIDR 规则，并添加 time.g.aaplimg.com Proxy 观察

[gemnioo]

另外 使用 黑白名单添加 不走代理的局域网设备 是为了远程NAT打洞使用. 最近折腾 Tailscale / 推友拿它开源版编译 加了国内 DERP 的 xEdge. 并不想回退到兼容NAT友好的 Redict HOST 模式

[refined-fish]

同求，另外能否请教一个问题，如果使用mosDNS前置分流，是否是指mosDNS转发非大陆请求到openclash？这是不是会导致openclash仅接到IP请求，从而 OpenClash只能IP规则分流（域名已经被mosDNS用掉了）域名规则失效？

还没有折腾过 MosDNS 是转发器 根据域名和IP表分流 https://songchenwen.com/tproxy-split-by-dns 如图 fallback 才用到DNS服务器解析成 IP 分流.

「 插件设置 - GEO 数据库订阅 把 GeoIP Dat 和 GeoSite 这两个库的自动更新打开，都选 Loyalsoldier 的版本，这个是用来给 mosdns 用的。 这里 mosdns 监听了 5335 端口。并且要在 GeoData 数据导出 里配置上我们用到的标签：GeoSite: cn, apple-cn, category-games@cn, geolocation-!cn, GeoIP: cn」

OpenClash 的绕过大陆IP 只有域名规则命中才走114解析 不属于大陆IP段的和不在域名规则的才入站 Clash 核. 应该问在域名规则中 但被114解析到国外IP 入站 Clash 是域名还是IP 我猜是 IP

很遗憾，尝试了，目前发现两个问题：

1. 第一个是MosDNS的配置方式相对比较简陋，维护不便，而且我甚至没能成功在非代理环境下启动它（所需数据库很难下载）。
2. 第二个是我仔细想了下文中的方式，纯DNS分流会使纯IP流量无法被代理，文中给出的解决方案依赖脚本和专有IP集去写规则，这样的解决模式较为繁琐，需要经常维护。

想要实现无论域名/IP流量都能被分流，大陆流量直接绕过clash，非大陆流进clash内核再根据域名/IP规则分流指定代理，并且对于大陆和非大陆均能访问的流量择优选择（例如代理更快的git，非代理不能用的bingAI），还要维护简单（多地使用维护不便）。
目前我还是采用单独的openclash+fakeip+meta内核+绕过大陆+自行添加部分规则（例如让bing不要绕过）的方式，之前没有试过fakeip，现在看看效果如何。

[gemnioo]

更新到 v0.45.141-beta Fake IP 增强模式 使用防火墙转发 黑白名单添加 不走代理的局域网设备 IP/MAC 192.168.2.21 macOS 192.168.2.10 Windows

后台查看日志如上两台设备还是进了内核 断电重启主路由 旁路网关后，日志内只会出该.2.21 macOS 有如下地址 WRN [TCP] dial failed error=dial 的请求

其中

2023-09-18 14:03:45 INF [UDP] connected lAddr=192.168.2.21:49838 rAddr=time.g.aaplimg.com:3478 mode=rule rule=SrcIPCIDR(192.168.2.21/32) proxy=DIRECT

Config 加了 - SRC-IP-CIDR,192.168.2.10/32,DIRECT - SRC-IP-CIDR,192.168.2.21/32,DIRECT 是为了保底

查询是 DNS TXT record 不知道Windows 设备为何也会有这个请求 ，黑白名单不走代理 等于添加了 iptable 规则分流。 观察日志仅有这条UDP请求进入到Clash

目前注释掉 - SRC-IP-CIDR 规则，并添加 time.g.aaplimg.com Proxy 观察

经过查询 发现终端设备 Config 文件内的 Fake IP filter 并不会被写入 需要手动配置TUN Mode 或者 Mixin 以上问题的产生是 类似打洞请求 controlplane.tailscale.com & *.xedge.cc 被 Fake IP 映射 走 169.254.0.0/16；100.64.0.0/16 出口 不能成功被OpenWrt 配置的防火墙黑白名单规则过滤 入站到OpenClash核 与其他内网其他设备占用的已存在的 80 443 端口请求重合导致路由表混乱导致的 还观察到同类型非本机发出莫名其妙的 wecha baidu weibo 等错误请求

经过终端Clash for Windows GUI 手动修改 TUN Mode 已解决

但又遇到以下 UDP 53449 41641 (Tailscale 防火墙默认开口 进入OpenClash
2023-09-19 09:45:56 INF [UDP] connected lAddr=192.168.2.21:53449 rAddr=198.18.0.1:41641 mode=rule rule=IPCIDR(198.18.0.1/16) proxy=REJECT
2023-09-19 09:45:56 INF [UDP] connected lAddr=192.168.2.10:41641 rAddr=198.18.0.1:53449 mode=rule rule=IPCIDR(198.18.0.1/16) proxy=REJECT
2023-09-19 09:45:56 INF [UDP] connected lAddr=192.168.2.21:53449 rAddr=198.18.0.1:41641 mode=rule rule=IPCIDR(198.18.0.1/16) proxy=REJECT
2023-09-19 09:45:56 INF [UDP] connected lAddr=192.168.2.10:41641 rAddr=198.18.0.1:53449 mode=rule rule=IPCIDR(198.18.0.1/16) proxy=REJECT

修改 插件设置---黑白名单----绕过核心的来源端口 添加 53449 41641 问题依旧 ~~ 😮‍💨

[github-actions]

This issue is stale because it has been open 60 days with no activity. Remove stale label or comment or this will be closed in 5 days

[yangzihaoku]

请教一下，如果想在Fake-IP模式下通过黑白名单控制局域网设备是否走代理的话（设置里依然用dnsmasq转发），能否在dnsmasq环节就进行分流处理？
在dnsmasq里添加一条：
dhcp-option=tag:customdns,6,114.114.114.114
dhcp-host=192.168.1.100,set:customdns
这样是不是可以既保留dnsmasq转发的选项，又可以在进入OpenClash分流前完成对设备的黑白名单控制

[github-actions]

This issue is stale because it has been open 60 days with no activity. Remove stale label or comment or this will be closed in 5 days