@mohumohu
倒也是，但 CF 除了 1.1.1.1 这种 IP 是 anycast 外，其全球 IP 段蛮多的，套了 CF 的同一个网站不同国家解析出的 CDN 地址应该是不同的。
比如我自己对于 pixiv 就是单独指定了日本线路的 DNS+日本出口，目前体验是完全 ok 的。
类似需求应该都可以通过 DNS+routing 同时配置域名解决，再配合 sniffing+destOverride 查缺补漏即可。

@Ipsum
你提到的 DNS 配置 fallback ，楼上已经有老哥给出了 ROS netwatch 的方法，可以在旁路不通时自动切换 DNS 服务器。
我最近会优化下，看看能不能直接监控对应软件而不是旁路由 IP 的可达性。

至于同一个 CDN 的下多个网站域名问题，先不论这个是否是一个伪需求。即，都解析到同一个 CDN IP 下的网站，真的有必要按域名拆开代理规则吗？

不过若是真想达到你说的效果，其实也是有办法的。
我描述的方案比较复杂，可能很多人没有认真看。究其原理，我只是告诉主路由：把命中这些 OSPF 动态路由表的 IP 流量转发给旁路由。除此之外并未做任何功能上的妥协，所以，原本全局透明代理具有的：流量嗅探，以及路由模块中，按域名匹配代理规则的功能，全都可以正常生效。
因此，你的这个规则只需要在开启流量嗅探，并且在 routing 模块中按域名指定不同的出口代理即可。

@mohumohu
嗨，这个就见仁见智了。代理的 DNS 查询流量和正常访问的负载流量并无二致区别，都会走同一套传输路径和代理协议。
要是说远程 DNS 不稳定，那等同于说科学线路有问题，本身的科学质量也绝对说不上好。

唯一我觉得会可能有差别的地方就在于，远端 DNS 解析可以省掉一个 RTT ，但对于一个近乎于一次性的工作来说，用“错误结果”去达成这个目的的代价也太大了些。
类似的 0-RTT 概念，在 HTTP/2/3 里，基本都是纯优势，也并未带来如此大的负面作用。

@mohumohu
ok ，感谢解答。我明白了
CDN 问题其实就是代理的 DNS 选择问题，socks5 之类的代理协议也可以承担远程 DNS 解析。
但 fakeIP 优先向本地应用返回分配好的假 IP ，然后再将进来的 IP 连接，反向匹配域名后，一并送往远端代理节点解析。使用远端默认 DNS ，一般来说可以得到较好的 CDN 匹配结果。

但实际上 DNS 查询往往是一段时间内的一次性工作，用错误结果去取代这个过程我不是非常赞同。
而且你提到的"同时也节省了 DNS 解析的耗时。" 这个说法应该是完全不成立的，DNS 解析没有被省略，这部分时间会被加到 TTFB （ Time to The First Byte ）里。

另外提到 fallback 问题，对于魔法来说，我认为最好的 fallback 就是有一个 Kill Switch ，一键下线所有配置，对原有拓扑不产生任何影响。做完全的可插拔化。这也是我一直坚持开发旁路由代理模式的原因。fakeIP 对原有拓扑影响实在是难以接受。

@Ipsum
... 感觉一直在跟我打谜语似的，fakeIP 和 CDN 又有什么关系吗？我提到的方案，国内网站也使用的是国内 DNS 的啊。
而且一直有人在讲 fallback ，我去翻了 clash 的文档，fallback 也不是提到的这个用处啊。

@Ipsum #53
说实话我已经解释的有点累了，fakedns 问题太多，我在上面的回复已经阐明了三大我不可接受的缺点。

那么我就再问一个问题，如果连接性一般的网站你也纳入了扶墙范围以追求更好访问体验，那你是希望扶墙有问题的时候，这些连接性一般的网站是因为 fakedns 污染导致完全不可用呢，还是靠 ISP 的路由保证基本能访问呢？

在我看来，一些东西的正确性是必须得到保证的，fakedns 是牺牲正确性去达成某些情况下的便利。就酱吧

@isAK47 #48
这个轮子造的确实有点重。目前我还在添加解析结果的动态路由，以及活动路由条目的自动续期(非 DNS 续期)，以达到更好的使用体验。

不过没懂你这句话的意思，什么叫“把常量整合在一块”?

@Ipsum #50
fakeDNS 的配置的确是最简单的，但它总是 fake 的~

世界就是依赖草台班子运行滴
stay calm

<来自楼主的召唤链接>

我看你描述的这个操作，其实和 dae 思路是一样的。
可以看看这里，其实你想的大部分操作 dae 都已经实现了 https://github.com/daeuniverse/dae/blob/main/docs/zh/how-it-works.md

不过不存在“路由器大多基于 linux”，“外包 nfqueue 这个说法“，同机器上用户态处理尚可接受，跨机器甚至要 RPC 的情况下，复杂度和可用性都会爆炸的。
而且高性能的路由器例如 ROS 这种，其都是使用的裁剪+高度定制化的 linux 内核，定制程度达不到你说的这么高。

@herozzm #33
那和我思路一样，只不过我是按需分流，你是!CHNRoutes 默认都绕一圈旁路。
ROS 配合自家硬件，稳定性和性能上没得说，几年不用重启，大部分路由功能都还有硬件加速，确实不是 openwrt 能比拟的。

话说你 watch 脚本监控 DNS 的代码能借鉴下吗（ ROSv6 的文档实在是不好翻）

@mohumohu #28
FakeDNS 的缓存有效期这个还真取决于客户端... 3 秒或者 1 秒明显是不可能的，有些应用甚至还有自己单独的 DNS 缓存（没错，chrome 就是）

自动化这点，从 geoip 规则文件载入 CIDR 这点还是不算复杂的。
至于开源数据的可信程度，一个要评估攻击面，另一个要评估攻击产生的后果。xz 供应链投毒的事情还历历在目，那个确实攻击面很大，后果也极其严重。
但对于各位魔法人来说，在开源规则里投毒可能不亚于关公面前耍大刀（笑。而且哪怕有问题，其造成的后果也完全可以接受。

顺带对楼上某些人重申一下，本帖的目的是分享和讨论解决方案，如果你喜欢，自然可以拿去用。
如果不喜欢，请你也不要大秀自己优越，无理由无根据的随口拉踩。

敢问，是你自己写了方案分析了利弊，还是亲自做了实现完成了目的？仿佛捡到一把香蕉逢人炫耀的猴子。

@mohumohu #26
从你的解释看来，我对“嗅探目标”存在误解。这点确实，只有连接性不佳或者被墙的域名会存在 FakeDNS 污染。
但是这一前提条件是建立在：使用 GFW 黑名单这一规则之上。

如果使用大陆白名单，则海外域名都会被污染，离开家庭网络后这一污染会持续到 DNS 缓存过期为止。
而且嗅探这一操作具有局限性：比如只能主要作用于 http 流量，以及 TLS 相关协议，后面还有 Encrypted SNI ，会使嗅探的工作环境进一步恶化。

静态路由问题，本方案下的静态路由只需要在配置里新增一行 "persistentRoute": ["geoip:telegram"] ，路由规则集的生效和更新是完全自动化的。而光猫之类的操作需要手动进行。

@mohumohu #24
1. 嗅探的前提是所有流量从代理软件经过，以 FakeDNS 作为路由分流的前提情况下，嗅探是无法实现的。
2. 推测说法，不予取信。而且方案正确性不应该依赖客户端行为。
3. 电信设备很难快捷方便的添加这种静态路由，并且保持无感更新。楼上我也解释过了，把配置分散到各处是管理起来心智负担很大的一种做法。
4. 不是所有设备都支持这种操作，和 2 一样，依赖客户端行为。

而且就 FakeDNS 的实现来说，其也存在“路由多一跳”的问题，而且还额外带来了 DNS 污染问题。

@FrankAdler #20
灵活，all in one 应该是本方案最大的优势。
传统的 dnsmasq+gfwlist+ipset 属于黑名单模式，全量载入规则或多或少会影响主路由转发性能。而且手动排除/添加规则都尤为麻烦，需要路由+代理软件配合操作。

本方案则是依个人喜好，GFW 黑名单，大陆白名单均可，而且可以依据个人需求灵活增删规则。还有我文末提到的，远程组网，DNS 分流，全部配置都集中在*ray-core 的配置文件里。

实现上，路由条目是按需通告+不活动废弃，包括*ray-core 的关闭都做了优雅停止，会自动从主路由上 flush 掉所有指向旁路的路由条目。结合社区活跃更新的 rules dat ，配置的心智负担和传统方案相比是降低了非常多。

@bluaze #19
高峰期问题确实不好解决，我 ISP 是电信并且有加钱精品网，目前 GFW 黑名单+部分定制黑名单的使用体验尚可。

你提到的这个，无法界定是否黑白的薛定谔域名解析方案确实蛮常用的。在*ray-core 的路由模块增加一个 geoip:cn 的直连规则，然后默认走 proxy 即可。但本质仍然属于大陆白名单模式，只是额外增加了国内 DNS 解析这一步骤进行可能的优化（但我认为存在 DNS 污染的风险）

mosdns 问题是其功能并没有*ray-core 这么全面，我其实不太在意这个东西会不会被上游接受，只是分享一个自己研究出来最适合我的方案。
尤其是 v2ray-core 本身模块化设计的很好（甚至有点过度设计），从代码层面来说都不算魔改，我只是增加了一个子应用进去，后期 follow 上游的更新应该问题不大。xray 粗略看了下代码删了很多设计模式，倒是代码直观了很多。

@jdjingdian #18 chnroutes 这个东西不是那么准确，基于 IP 的规则更新频率和准确度都是远不如域名规则的。所以这个也是我开发本方案的原因之一。
另外一个原因就是，如果被转发到透明代理的流量被 direct 出去，TCP/UDP 流量还好，一般来说默认会被透明代理 srcnat 掉，而其他类型的 IP 报文则直接会产生环路。这也是上文提到并解决掉的一个问题。

@cnbatch #16
感谢解释… 我个人有蹭朋友专线倒是没留意过 UDP 传输层的这些问题。
*ray 圈子这个风气我不好评价（当然就你链接这个情况，确实有点离谱），我个人也只是使用并未深度参与。
QUIC 问题 v2ray 和 xray 据我所知应该都是单纯 follow 的上游实现，不愿意去针对魔法适配一些东西可以理解。

@cnbatch

@cnbatch #14
底层走 UDP ，属于 Transport ，KCP/QUIC 都是基于 UDP 实现的，你所希望的应该是可以通过这俩传输层协议支持的啊，上层代理协议无所谓，只要传输层协议是 UDP 就可以了。