@zbatman
没问题，v2ray 的出站 DNS 流量一样可以匹配出口，这点你根据需求自由配置即可。

举个例子：我有两个 1.1.1.1 的 DoH DNS 服务器配置，一个匹配域名写了 pixiv ，另一个作为默认兜底。
前者的 DNS 查询流量可以被标记为 dns-jp ，后者标记为 dns-default ，然后路由模块添加 tag 匹配规则，来源为 dns-jp 的流量，送往日本节点即可。

@zbatman
就是正常的 v2ray DNS 模块，支持所有配置规则。
具体取决于你希望国外域名怎么配置。

比如我是 geosite:cn 和部分我个人指定的域名走 ISP DNS + DNSPod 做备份，其余不命中规则的域名，默认走 DoH 1.1.1.1 从代理解析。
策略选择 disable-fallback-if-match ，避免国内域名超时后请求国外 DNS 。

@terrancesiu
使用 ROS 的用户可以参考下我前两天发布的旁路动态路由方案：DNS 嗅探+ROS 路由表分流，旁路拓扑完全可插拔。所有旁路配置集中管理。

@wawaguo #20
全部流量都走软路由的透明代理模式，或多或少会有一点影响。
而且部分游戏会有奇奇怪怪的连接问题（取决于代理软件的 NAT 行为）
可以参考 dae 的 issue 区反馈，虽然 dae 是 fullClone NAT ，但确实还是有一些反馈问题的。

@Jirajine #9
同意，这一点是个 concern ，受害者说法有点夸张，对于黑白名单以外的未知域名，现在形势应该还没坏到那种地步。
我个人不推荐这种方式的原因，还是国内 DNS 可能返回污染后的国内 IP ，这种情况下是没办法分辨出来的。

当然前面有人提到的反诈上门问题，这个应该还是基于现在各种运营商的 SDN 网关/云宽带模式做的。自己走桥街拨号绕过运营商终端网关上的一堆“安全插件”就没什么问题。

魔法师们果然都不缺创造力。
Redirect 和 Tproxy 应该是二选一的关系。有 tproxy 可用应该无条件选择 tproxy 。
你描述的这套配置下来也不轻松，除了网关是无条件走一遍软路由，以及网关故障转移外，没什么其他致命缺点了。
唯二问题就是：
* 低性能 ARM 设备需要打个引号，这个性能要能满足：使用 iptables 可以承受全部网关流量，否则哪怕不用魔法还是会卡。
* 涉及工具太多了，配置分散在各处，需要相互配合。想简化的话可以用 debian+gfwlist+mosdns+dae

@isAK47
明白了。方案我还在持续改进中，目前还在修改动态路由条目的续期机制（ DNS 解析续期+实际流量续期）。
差不多等我把方案完备后，可能会单独开一个项目来给出示例。

@mohumohu
完全同意嗅探的局限性。目前包括 v2RayNG/v2RayU 等一系列 GUI 客户端的默认配置，都是 DNS 留空，只依靠流量嗅探+大陆白名单路由模式提供魔法。这个操作我怀疑在 encrypted SNI 普及后会失效。

但我还是保留意见吧，fakeIP 的代价对我来说实在是太大了些。
打个不恰当的比方：梯走影还在，磕绊留三代。

@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 的文档实在是不好翻）