塑料壳的交换机 只要烫了都有这种问题。

另无线之间的 iperf3 ，具体得看多慢，你要知道 无线射频是共享宽带，一边上传一边下载一起打，不是全双工哦。

是不是海康的硬盘录像机子网掩码配错了，设成 255.255.255.0 肯定无法跨网段连接吧。硬盘录像机也得配成一样的 255.255.192.0 子网掩码。录像机改成 DHCP 才能联网应该也是这个原因，你子网掩码和路由，DNS 配置错误了。

另外 DNS 问题，有些移动的网络是不能使用 114 的，能换成阿里云的 223.5.5.5 。

这点网络找萤石没有用的，人家是 To C 客服是不懂这些。能得找第三方网络人员，或者让幼儿园出个监控维护包，分包给移动，立刻给你解决。

意思是不是所有的监控都接到散落在各个地方的 ZXA10 F822 ，用这个设备的 POE 供电？
如果线路都是集中在一个地方，直接买个 poe 供电交换机，加个路由器不就解决了？才多少钱。

哈哈，如果楼主看到 windows 的注册表，估计洁癖都犯嘛了。vscode pio 丢到 用户目录下的几十 G 的小文件，删都得删几个小时。

@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 对设备性能也是一种损耗，维护复杂度也增加了，当然这种损耗和复杂度不值一提，但这是因为网络拓扑的问题而导致的。那么为什么不直接在拓扑上解决这种需求？如果我维护的还有其他机器，那么维护难度就增加了。最直接的方案还是基于目的地分流，这个流量是要跑到梯子的，就跑到梯子，是直接出去的，就直接跑出去。