@ambition117 #119 你说的是正确的，非大陆 IP 全部导到 clash 。只是大部分人域名已经足够，我用的是这套规则，已经足够了 https://github.com/blackmatrix7/ios_rule_script/tree/master/rule/Clash ，其余自定义域名我自己维护了一份规则，修改后实时更新到 coredns 上，coredns 会定期更新规则，过程是自动订阅的，不需要人维护。并非所有人的硬路由都能添加大陆 IP 全表到路由表里。另这个路由表其实还是需要维护的。

只是你说的这种方案需要获得真实 IP ，这样 fake-ip 优势就没有了。

mosdns 的 chinadns 的方案我没有了解过，但听你这样说，我感觉和 DNS 分流没什么区别？

tp mesh 就行了 去 acwifi 看看

qx 直接用 ss 回家就好了 一样用啊。surge 也行就是太贵

我个人是 photos 和 drive 两个用的粘度较大。

@oovveeaarr #101 而关于非 TCP 、UDP 流量代理问题，这个就看需求了，大多人需求只是这两个协议。如果你有这种需求，那可以采用基于 L3 的代理。甚至 L2 的也行。
所以一切得看需求。

>>加速的 IP 地址不一定是被墙的，被墙的 IP 地址流量也不一定是 TCP/UDP 的，太局限了。

@oovveeaarr #101 这个涉及到成本问题，你如何确定 IP 被墙？如何确定直连或者代理能获得更好的体验？这些都需要成本。所以一贯做法，直接订阅大家维护的域名规则库，匹配到规则库则直接跑出去代理服务器，例如 github 某些地区，的确能获得很好的链接体验，但偶尔有一天墙调整了，可能会偶尔抖动，也可能以后都无法连接。这时候需要调整它们就增加维护成本，还不如直接订阅大家维护的规则库，即使你这边能直连，但是代理也不会有太高的成本。以上是我个人的看法。GFW 不可控，我只能控制自己的梯子。

@Bluecoda 游戏一般是小包，而硬件路由简单的防火墙策略情况下，小包直接由芯片处理转发的话，效率肯定会比软路由的软件转发快，至于快多少。对于你是否有帮助，取决于你当前网络的小包转发量。

例如有些人什么业务都不跑，就玩游戏，路由只需要处理你的游戏 udp 小包转发那么肯定没问题。

但如果是家里跑了很多业务，小包大包各种流量都有，同等情况下，硬件转发必然比软件转发效率更好。

其实我这套方案，很早恩山就在玩，只是人家用的是 ikuai DNS 分流功能 https://www.ikuai8.com/zhic/ymgn/lyym/lkfl/ea195/75960.html ，ikuai 是支持设置 DNS 域名匹配后，把流量转发给另一个机器。这种配置简单。

缺点就是无法动态更新规则库（当然你可以手搓脚本 用前端 API 操作更新。）
优点就是配置简单

只是很多人不喜欢用 ikuai ，因为有后门嫌疑。

>> 这些用户搞更复杂的网络，他们收益其实很低，除了能自娱自乐，回帖秀下优越感之外，对网络改善效果非常少。

这样说，一切以需求出发。相信弄更复杂的网络用户并非为了自娱自乐，每个人也有自己需要解决的痛点。
只是楼主在谈论最佳实践，站在网络的角度，每个人有不同的理解。

对于局域网里跑 PCDN 和 PT 的用户一台逻辑设备混合各种业务，基于源 IP 地址的分流（手动修改网关和 DNS ）在我看来，并非最佳实践。

网络的事，交给网络设备去做。docker 划分 macvlan 分配多个 IP ，这种做法的确可以解决需求，但我看来，并非最佳实践。

@cocomiko 这样的做法就是一刀切，爬墙的机器如果连国内的流量依然是要跑到 openwrt 。例如我某个机器上跑 了 docker 里面有 qbittorrent 和 emby 。那么 emby 搜刮的时候需要爬墙，但 qbittorrent 流量跑到 openwrt 会损失性能，这样就很麻烦，需要对 qbittorrent 做 macvlan 分配一个独立的 IP 给它。多了一层 macvlan 对设备性能也是一种损耗，维护复杂度也增加了，当然这种损耗和复杂度不值一提，但这是因为网络拓扑的问题而导致的。那么为什么不直接在拓扑上解决这种需求？如果我维护的还有其他机器，那么维护难度就增加了。最直接的方案还是基于目的地分流，这个流量是要跑到梯子的，就跑到梯子，是直接出去的，就直接跑出去。

@shijingshijing 其实软路由主要是小包并发和多线程问题。但是这些问题一般不会出现在家庭网络里。

@sun82kg 您的方案的确更简单，还做了静态 DNS 分流。已收藏。

@oovveeaarr #57 fake-ip 仅仅只解析给爬墙的域名，既然爬墙的域名必须走代理，那么爬墙的流量的网络的完整性还有必要吗？对于国内域名，获得的 IP 地址是真实 IP ，在国内流量里，是完整的网络。icmp 等协议都是一样的跑法。

> ping www.bilibili.com
PING www.bilibili.com(240e:97d:2000:c0e::30 (240e:97d:2000:c0e::30)) 56 data bytes
64 bytes from 240e:97d:2000:c0e::30 (240e:97d:2000:c0e::30): icmp_seq=1 ttl=56 time=8.10 ms
64 bytes from 240e:97d:2000:c0e::30 (240e:97d:2000:c0e::30): icmp_seq=2 ttl=56 time=9.11 ms
64 bytes from 240e:97d:2000:c0e::30 (240e:97d:2000:c0e::30): icmp_seq=3 ttl=56 time=8.89 ms
64 bytes from 240e:97d:2000:c0e::30 (240e:97d:2000:c0e::30): icmp_seq=4 ttl=56 time=9.95 ms
64 bytes from 240e:97d:2000:c0e::30 (240e:97d:2000:c0e::30): icmp_seq=5 ttl=56 time=9.65 ms
^C
--- www.bilibili.com ping statistics ---
5 packets transmitted, 5 received, 0% packet loss, time 4006ms
rtt min/avg/max/mdev = 8.102/9.138/9.949/0.640 ms
> ping www.bilibili.com -4
PING (59.36.228.17) 56(84) bytes of data.
64 bytes from 17.228.36.59.broad.jm.gd.dynamic.163data.com.cn (59.36.228.17): icmp_seq=1 ttl=56 time=4.86 ms
64 bytes from 17.228.36.59.broad.jm.gd.dynamic.163data.com.cn (59.36.228.17): icmp_seq=2 ttl=56 time=5.31 ms
64 bytes from 17.228.36.59.broad.jm.gd.dynamic.163data.com.cn (59.36.228.17): icmp_seq=3 ttl=56 time=6.23 ms
64 bytes from 17.228.36.59.broad.jm.gd.dynamic.163data.com.cn (59.36.228.17): icmp_seq=4 ttl=56 time=4.36 ms
^C
--- ping statistics ---
4 packets transmitted, 4 received, 0% packet loss, time 3001ms
rtt min/avg/max/mdev = 4.359/5.189/6.231/0.689 ms
> ping www.google.com
PING www.google.com (198.18.0.3) 56(84) bytes of data.
64 bytes from 198.18.0.3 (198.18.0.3): icmp_seq=1 ttl=60 time=1.33 ms
64 bytes from 198.18.0.3 (198.18.0.3): icmp_seq=2 ttl=60 time=1.06 ms
^C
--- www.google.com ping statistics ---
2 packets transmitted, 2 received, 0% packet loss, time 1000ms
rtt min/avg/max/mdev = 1.056/1.193/1.330/0.137 ms


> traceroute -n www.bilibili.com
traceroute to www.bilibili.com (59.36.228.17), 30 hops max, 60 byte packets
1 10.89.0.1 1.180 ms 1.107 ms 1.103 ms
2 *.*.*.* 2.914 ms 3.292 ms 3.240 ms
3 14.148.6.89 2.624 ms 14.148.6.81 2.461 ms 14.148.6.89 2.555 ms
4 14.148.2.149 3.421 ms * *
5 * 183.61.221.138 9.633 ms 183.59.12.2 5.502 ms
6 * * *
7 59.39.4.62 3.892 ms 183.57.144.2 3.880 ms *
8 * * *
9 59.36.228.17 4.533 ms 4.185 ms 6.581 ms
>
> traceroute -n6 www.bilibili.com
traceroute to www.bilibili.com (240e:97d:2000:c0e::32), 30 hops max, 80 byte packets
1 240e:*:*:*::1 0.323 ms 0.302 ms 0.273 ms
2 240e:1e:8000::56 1.701 ms 1.837 ms 1.735 ms
3 240e:1e:851d:2::1 1.501 ms 240e:1e:851d:1::1 1.462 ms 240e:1e:851d:4::1 1.471 ms
4 240e:1e:8401:12::1 2.844 ms 2.833 ms 240e:1e:8400:10::1 4.915 ms
5 240e:1f:d000:ff00::3 5.146 ms 6.149 ms 240e:1f:d000:46::3 6.292 ms
6 240e:1f:d000:83::3 4.908 ms 5.018 ms 240e:1f:d000:85::3 7.331 ms
7 240e:97d:2000:900::69 4.145 ms 240e:1f:d809::e:3 6.757 ms 240e:1f:d809::c:3 8.398 ms
8 240e:97d:2000:900::65 3.519 ms 240e:97d:2000:900::69 6.590 ms 240e:97d:2000:c0d::3 5.176 ms
9 240e:97d:2000:c0d::1 7.611 ms 240e:97d:2000:c0d::3 5.074 ms 240e:97d:2000:c0e::32 4.462 ms
> traceroute -n www.google.com
traceroute to www.google.com (198.18.0.3), 30 hops max, 60 byte packets
1 10.89.0.1 0.418 ms 0.317 ms 0.306 ms
2 172.16.222.2 0.914 ms 0.935 ms 0.885 ms^C

“旁路由”，在传统网络上是不存在这种说法，只有单臂路由，策略路由。
其实什么路由都无所谓，能解决问题就是好路由。
每个人也有适合他自己的解决方案，自己觉得好就行了。
最佳实践，这个看哪个角度了，例如你觉得硬路由做主路由，其他需要爬的机器采用修改网关 dns 来实现出墙功能，那么你觉得这样方便维护，那么是没问题的。
我最早折腾是搞 openwrt 做主路由，当年还没有什么插件，都是自己手动搭的，根据 IP 表分流，dnsmasq+ipset+ iptables+ss-libev （ redir ）+pdnsd 组合来解决 dns 污染和分流代理
但是这种组合维护特别不方便，ss 的服务更新，分流出问题了调试麻烦（组件太多）
后来 surge 出现后，陆陆续续的 ios 小火箭 qx 等基于规则的代理工具也出现，clash 也同步出现，逐渐成为了主流工具。
我也把 openwrt 的代理工具换成了 openclash 。
优点是：有 web 面板，切换节点，日志查看都非常方便。
缺点：openclash 想做 clash 的 web ui 客户端，想把 clash 的配置全部丢到 web 上方便用户配置和修改，确实做的很棒，但这样脚本的代码量非常大。试过几次因为 openclash 更新订阅的时候可能因为网络抖动问题下载下来的是空文件，但他不会校验（现在不知道会不会）。导致 clash 直接不启动了，不启动他也没有清理 iptables 等配置导致直接断网。（现在应该修复了？没再用了）

后来了解到 Mikrotik RouterOS ，就入了一台弱电箱神器。开始玩 Mikrotik 系列路由
对于本来就是学网络的人，routeros 其实比较适合，界面直观，配置概念完全是按照网络概念设计，如果你熟悉网络通信原理，熟悉防火墙配置，那么玩 ros 其实并不难。

但换了这个硬路由，爬墙怎么搞呢。我一开始也学大家一样，做“旁路由”（其实就是多层 NAT 路由），那么根本没法解决 openwrt 单点故障的问题。而且 NAT 转换效率，根本没有发挥硬路由的优势。

后来搜到的解决方案都是说例如你某个机器要爬，可以让 dhcp 服务器根据不同的 mac 地址分配不同的网关，或者是手动设置网关和 dns 。

我觉得这种方案太麻烦了，例如我某个设备今天突然需要访问一下 google ，只是突然需求，我还得电脑开机路由上配置，即使 Mikrotik 有手机客户端，我也需要等待 dhcp 生效，或是手动配置网关和 dns 。

我认为这个需求能直接从主路由上解决他们，后来也了解到各种代理工具都在用 faek-ip 方案。理解了工作原理之后，我就针对家里现有的网络拓扑进行修改。

最终采用 硬路由+dns 分流+fake-ip （ shellclash ） 的方案：
优点：
- 完美的分流：分流完全取决 dns 规则，只要匹配规则才能拿到 fake-ip ，fake-ip 的流量才会跑到 openwrt 那边，国内流量是直接从主路由就出去了。根本不会到 openwrt 那边。
- 网络性能：所有流量都先到主路由，主路由根据路由表进行流量转发，这是硬件路由的强项，所以基本不会有性能消耗，即使是最垃圾的 tplink 家用路由器，他也能完美的完成这个需求。因为得益于 fake-ip 方案（出自 https://www.rfc-editor.org/rfc/rfc3089 ），出墙的流量不需要获得真实的 DNS ，也不需要等待 DNS 答复，能以最快的速度封装 IP 层后发起访问。
- 维护便利性：因为只采用 dns 分流，所以只需要关注 dns 分流情况即可，拿到 fakeip 的流量才会跑到 openwrt 那边去。如果 dns 炸了，脚本能够自动检查并切换主路由的 dns （ Mikrotik 带脚本功能）
- 完美兼容 ipv6：因为对于局域网设备而言，他们只有一个网关就是主路由，所以和普通的网络是一样的，ipv6 自然就不受影响，而爬墙流量，因为 dns 服务器回答 fake-ip ，根本没有 ipv6 地址，所以自然也不受影响。
- 自动愈合（ Mikrotik 独有）：通过 Mikrotik RouterOS 的脚本功能，定期检查 openwrt dns 服务，如果出现故障，立即切换 ROS 的 DNS 上游服务器为运营商 DNS 。路由表则完全不需要管，因为运营商的 dns 不会回应 fake-ip 给你。
缺点：
- 依然存在（非主路由的）单点故障：因为 DNS 分流靠第三方服务，所以如果 DNS 服务器挂了，会导致整个网络的域名解析出现问题。我做法上面也说了，如果出现故障，立即切换 ROS 的 DNS 上游服务器为运营商 DNS 。
- 对非网络专业人员而言，有配置难度。（其实所有透明代理都需要解决 dns 和路由问题，只是人家把这个过程放到 openwrt 脚本里帮你自动配置而已）

这方案我已经用了快两年，几乎 0 运维。这也是我个人认为翻墙网络的最好实践

删除没用的，他要控制你，直接可以加回来的。

@YongXMan #9 那么最好的做法还是用主路由来控制转发流量，这样就有一个很清晰的路由表去表达流量的走向。iptables 的 redir 或者 tproxy 方式，调试起来也是很费劲。特别是 openwrt 这种系统，各个网络插件都要对 iptables 修改一下。难免出现兼容问题，前端按一下，不看他又臭又长脚本，根本不知道他做了啥。

@YongXMan #5 https://www.v2ex.com/t/947864#r_13206481 参考这里的方案，不一定要旁路由，可以部署在一个路由上的。

原理是前置 DNS 分流，匹配 fake-ip 才发送给 clash 。如果嫌麻烦就直接虚拟多一个 op 。

dns 分流，匹配域名才用 clash 解析。

443 80 默认被 ben 如果路由是光猫，需要配光猫的防火墙。另外先试试 fe80 的地址通不通，不通检查程序是否监听在 ipv6 上