@maybeonly #34 感谢分享思路！
这个问题我个人猜测应该是不会那么痛，但是明显还是大佬思考更细致。

我赞同你对现实情况的考量，只要路由选择上添加 srcIP - dstIP 做匹配，把不同终端的路由选择分割开，就能极大缓解这一问题。
目前我自己的实现是：只做了 dstIP 的路由规则，后续会抽空加上大佬的 srcIP 路由匹配策略。

另外咨询一个问题，大佬的 DNS route 的有效期是怎么计算的？什么时候废止这条路由表？
是靠客户端的 DNS 请求刷新吗？

@Jirajine #36
不能算在错误的 layer 解决问题吧，只能说是：把解决的问题的阶段下沉，对内网终端设备隐形。
然而把方案下沉，其实哲学意义上，就意味着解决问题时能获取的有效信息会减少。
这和运营商选择把反诈插件放在用户侧光猫里是一样的道理，只有足够贴近用户，才能提高反诈预警的准确性（只是举个例子哈，不对反诈这个东西做任何评价。

说到底，我和 OP 的哲学是一样的，能在网关解决的问题绝不在客户端上解决。

@maybeonly #24
DNS 分流实现思路和我一样，都是“不过墙的网络完全不走梯子”，但是我选了继续完善旁路由方案，对于 conntrack 部分我还是依赖主路由的路由表和防火墙的。给你这个全手搓的 DNS 分流跪了 Orz

不过我的帖子里，@mohumohu 提出了一个很有意思的问题：
有些网站会有区域限制，全真 IP 的情况下，如果两个网站解析到同一个 anycast IP ，而且域名嗅探失败的情况下，基于 conntrack 这一套 L3 的分流，如何正确选择代理隧道？
举个例子：假设 Netflix 套了 Cloudflare 的 CDN ，解锁 NF 需要美国 IP 。假设 DMM 也套了 CF 的 CDN ，解锁 DMM 需要日本 IP 。但因为 CF 的全球 CDN 网络，这两个站解析出的 IP 地址都是同一个 anycast 地址。

代理实现越靠下层，则会损失越多偏上层的信息。
我思来想去感觉很无解，随着 http3 和加密 SNI 普及，IP 数据包中的域名嗅探会变得越来越难，那么全真 IP 下的域名分流机制可能会始终面临这个痛点。

@MikuM97
上海电信去年五月取消了达量降速的条款，现在也是枪打出头鸟，如果你敢一个月上行十几 T ，那就是 pcdn 停机警告

分流思路和现在各种代理 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 的代价对我来说实在是太大了些。
打个不恰当的比方：梯走影还在，磕绊留三代。