分流思路和现在各种代理 core 差不多，而且在 dns route 上也摒弃了 FakeDNS 的路子好评。
但是，什么？你用 C++写的？还搓了这么多轮子？这是真大佬惹不起惹不起。

@mohumohu
哎，一并回复你 88 和 89 楼的问题吧
#88
本文的前提是：家庭网关层面的透明科学方式，并不是“管理一个企业级网络”。
我理解，各种各样的网络配置都有其优缺点。所以不存在一种完美的解法：你选择接受 FakeIP 的负面影响，我选择更复杂的方案，但是根除 FakeIP 的负面影响。

但，有一点应该是明确的：哪怕是一个“企业级”网络，放任“自助配置”，绝不是一个好办法，花样性配置才会带来更大问题排查和稳定保障难度。管理员本身是绝对没有那么多精力去挨个检查并测试个性化配置的。

另外，我所希望的特性已经在开头完完全全的讲明白了。我需要的是 all the same ，with no exception 。你一直在反复质问我怎么解决 exception 。这一点就讲真有些离题了。
所以我更希望大家能在同一个 context 下讨论问题。而不是“教我企业级网络应该具有什么特性”。

#89
OK ，来回答你怎么在网关上处理 exception 的问题。
用伪代码表示一下吧，可以理解为作用于 linux 的 postrouting 规则链上。
1. 不对称路由方式
from {某个内网终端设备 IP} to {旁路由 IP} proto=UDP and dstport=53 redirect-to {主路由 IP} port=53
2. 对称路由方式
from {某个内网终端设备 IP} to {旁路由 IP} proto=UDP and dstport=53 dstnat-to {主路由 IP} port=53

@mohumohu #85
DNS 问题两个方案没有本质差别，完全取决于怎么用。。
而且作为应用层的一部分，把 DNS 算进拓扑有点牵强。

罢了，我回复你的问题吧。
* 将主路由 DHCP 下发的 DNS 服务器改为旁路由 IP
* 主路由 DNS 不变，使用 ISP DNS
* 如果不需要科学，也有两种方案
1. 自己把设备的 DNS 手动改成主路由 IP
2. 在路由上写一条防火墙转发规则，将指定设备访问旁路由 IP 的 DNS 请求 redirect 至自身。（这种情况是非对称路由），也可以使用 DSTNAT ，保证对称路由。

所以你看，有区别吗？
何况，我所做的一切，都是为了让内网终端设备“完全感知不到代理存在+最大程度保证主干网络稳定与正确”。
因而，本方案下的旁路由是完全可插拔的，哪怕不做任何设置，直接拔网线也不会影响到主路由正常工作。
你这个“某个设备不想使用代理”的要求属实有点范围外了。

@mohumohu #82
拓扑侵入问题，FakeIP 需要操作两点：
* 手动添加静态路由
* 手动修改主路由 DNS
并且，故障降级前提是：旁路代理软件工作正常。如果旁路彻底挂掉，除了恢复主路由 DNS 配置外，还无法立即降级，因为 DNS 污染还会持续一段时间，并导致这段时间内路由选择错误。

OSPF 方案，只需要操作一点：
* 不需要手动添加静态路由
* 手动修改主路由 DNS
故障情况分两种：
1. 代理节点故障，则降级行为取决于使用的代理软件本身，FakeIP 和 OSPF 两种方案无异。
2. 旁路故障（包括：旁路 IP 不可达，旁路由代理软件崩溃），FakeIP 无法立即降级（原因上面讲了），OSPF 路由可以立即失效，此时路由选择完全正常。

DNS 降级方案 FakeIP 和 OSPF 共通，就不详细叙述了。
所以，综上所述，我认为 OSPF 是对拓扑影响最小的一种方案。

DNS 缓存问题，个别平台的规则，肯定是不能拿来当范例使用的。
网关遵循并使用的方案，应该是放之四海而皆准的。所以正确性这点我不打算妥协。

CF 分配 anycast 地址这个现象，你我都是就现状进行猜测。所以确实没有争论价值。
就要解决的问题来说，结合我之前提到的方案，我提出两个解决方案：
1. sniffing + Domain routing rule （基本所有代理内核都支持）
2. OSPF 路由通告/32 掩码的路由，降低 IP 和网站重叠的可能性，这点我已经作为默认设置了。

而且除去 FakeIP 这个方案外，你提到的“多个网站分配同一个 CDN 地址”这个问题，在其他代理模式下有且仅有通过 sniffing 解决。
除非将代理协议上移至应用层（例如：socks5 ），由应用本身通过代理协议，直接告诉代理软件它要访问的域名。这样才能保证域名分流准确。
总之，有舍必有得，如果将代理行为下沉，则必然会损失上层的一些信息，这些是正常的 tradeoff 。

@zbatman
> 扶墙挂了就通过“完全不能访问”来提醒我
这个其实取决于如何定义“扶墙挂了”，上面讨论中的扶墙挂了=旁路由完全不可用，而不是代理节点故障。
在默认配置下，如果不对代理节点做探活，代理节点连接出现问题，其实也会导致你没办法访问扶墙的网站。如果你在配置中明确了代理探活不可用就降级直连的话，才会出现你说的类似“DNS 泄露”的问题。

至于代理软件崩溃，以及旁路由实例故障，这种情况属于小概率事件，在我目前设计下，会造成旁路由从网络拓扑中直接消失，而完全不会影响主网络拓扑结构。

> 国内返回真实 ip ，国外请求 clash 返回 fake-ip 。即使 clash 挂了，不用任何配置，都不影响国内流量
这个前提条件是，国内外网站划分是准确的。实际上嘛，很难。
举个灰色的例子，比如 GitHub ，属于半墙不墙的状态，平时肯定直接走代理保证访问体验。但如果扶墙寄了，我这时候又因为某些事情不得不直连访问。那么 fakeip 带来的污染问题会让我一个头两个大。

其实讨论了这么多，我核心的诉求可以概括为一句话：旁路由在拓扑中存在与否，只通过一条命令 systemctl start/stop v2ray 来实现。
旁路由的优势就是，其对于除网关以外的设备完全隐形。所以我对它的要求是，悄悄的来，悄悄的走，不留下任何痕迹。这也是我哪怕自己耗费 2 周时间手搓 OSPF 也不使用 fakeIP 的原因。

@jink2018us
视频很好，适合入门。但感觉有点故意混淆旁路和 FakeIP 按需分流的概念。
另外，视频中提到的所有的旁路由问题其实都已经被我解决了。

@terrancesiu #39
不能，鉴于国内目前 ipv6 的环境，短期内不考虑做 ipv6 支持，开发成本不划算。

@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 对原有拓扑影响实在是难以接受。