@ambition117 #130 @oovveeaarr #131 其实我不用 real ip 主要麻烦是在主路由需要设置国内路由全表，我目前的情况无法能百分百确定路由表准确性（我没 BGP 收表，我也没 vps ，梯子是买的，这也是大部分人的场景。）另是我主路由是 MikroTik RB750Gr3 那么大的路由表对它而言也是一种负担。
论拓扑兼容性，fake-ip 不挑主路由，即使你使用电信光猫来作为路由依然可以达到使用的目的。对于大部分普通人，爬墙流量占比是网络总流量的 10%以下，fake-ip 我觉得是比较适合大多数人。
如果是重度使用爬墙服务，那么就需要对设备或者拓扑进行适配了。简而言之一切按照需求来。

我的需求：
满足拓扑兼容性（主路由是否什么设备都可以？）
维护便利性（需要维护多少个模块？排查问题是否方便，例如能否手机打开一个 web 页面就能维护而不需要敲终端命令）
网络性能（主路由内存弱鸡的情况下依然能适配，且不影响国内流量转发）

fake-ip 我觉得是比较适合我。

至于缺点：
假地址导致某些程序内置 DNS 挟持校验无法联网（目前我家里的应用不受影响，我也不看奈飞，更多的还是挂 PT 自动下载本地观看）
破坏网络完整性？（对我而言，匹配了 dns 规则的地址我根本不关心它完不完整，他流量能去到梯子那头就足够了，我又不是天天在家里监控这个网监控那个网····）

处于以上考虑，所以我没部署基于 Real ip 的硬+软路由方案。

@redial39 #127 变慢并非不能访问，例如馒头等一众 PT 站的 IP 地址，收集和维护他们，还有 BT 的连接，这些 IP 需要处理呢，虽然可以在路由根据源 IP 地址或者端口协议来做策略，但我个人觉得对于未墙 IP 走 ISP 出口变慢这点成本并未大于我要维护局域网内 BT 机器源 IP 协议等防火墙规则（忘记配置导致流量跑到梯子那边）。
目前基于上面所说的域名规则，基本涵盖了我所使用的墙外服务。

这是每个人需求不同，所以相对应的维护成本也不同，有的人喜欢 ROS tun 到 vps 收 BGP 路由，国内外分流，直接三层下分流，最准，也零维护。只是相对我而言，我目前方案已经满足需求，我就不再花成本去折腾了。

哈哈，抛开需求谈平台是否适合，你~你耍流氓~（脸红）

manjaro 对桌面不熟悉的新手，这货是最舒服。

@ambition117 #125 大概理解了，国外的 CDN 友好其实不需要关心，因为代理服务器那边还是会重新查一次 DNS ，根本不会走你当前 DNS 获得的 IP 。

特别是 clash 那种多规则多服务器，你 DNS 从哪里查？例如有 美国，香港 两个服务器，你上游 DNS 是 1.1.1.1 ，你从香港查，返回的肯定是香港友好的 CDN IP ，但这个域名其实规则是走到美国节点，所以只要确认这个流量是被代理，那么就返回 fakeip 这样就好了。

fakeip 缺点主要是例如你想排查国外的域名或者被代理的域名链接的时候会比较麻烦。这个 ros dns static 里配个 FWD 即可，例如馒头的域名我直接在 ros 上配置 FWD ，这样不管我的 coredns 的规则里有没有馒头的域名，我馒头的域名都是会向运营商的 DNS 查询。

国外未墙的 IP ，也不会放到 dns 规则里，不在规则里的自然就是从本地运营商 DNS 查询（例如梯子服务器的 dns ）这样其实是一样的。只需要维护一套规则即可。

其实你方案和我的差不多，大家都是用 dns 服务器根据规则向两个上游服务器查询 DNS ，最终确认该流量是否被代理。

@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 运维。这也是我个人认为翻墙网络的最好实践