我公司目前是用原生构建+expo 库，expo-cli 的那套构建方式感觉不太适合稍大一点的项目

@bitfly 如果你这么认为，那一定是没有经历过一炸全炸

@chenbin36255 iKuai 的虚拟机性能比较差，Docker 也比较难用。低价的 iKuai 开的虚拟机肯定是不如物理机的性能强的。不过我就是你说的这样部署的，网络设施都在一起，比较好维护。

@yyysuo 外服游戏本身也最好还是用加速器吧，靠代理打游戏本身就费点劲。

@Dk2014 其实理论上是可以把 gateway 换成普通的 clash 的，从而支持 arm 。

@povsister 有个疑问，这个方案，是不是还是需要黑白名单？只不过没有用 Fake-IP 而且返回 Real-IP 之后再去连接的？

@yyysuo 其实也没太看懂所以……我是真的菜。

@povsister

刚刚看了一圈你的方案，有点牛逼的，讲道理是很想部署一下试试的。

但是方案里面主路由用的是 ROS ，这个东西自己玩不太转，也不太好安利。并且硬路由不是很好搞。这东西能替换成 iKuai 或 OpenWRT 吗？

@povsister

我只是没能理解。
你分享的方案我也会仔细研究的，人外有人天外有天，学无止境我是懂的。也许我研究了你分享的方案，自然就理解你的想法了。

@povsister
那这个时候问题就出现了，github 这种灰色的，是否能取到 Real-IP 呢，能取到说明可以直连，不能取到说明连不上，那走 Fake-IP 又有什么问题呢？

现在应该不存在什么方案可以在直连失败的时候自动切代理，检测到可以直连再自动关代理吧？

理论上不应该都是黑名单/白名单模式吗？

@povsister
@bobryjosin

需要 Real-IP = 可以直连 = PaoPaoDNS 直接解析
不能直连 = 可以使用 Fake-IP = PaoPaoDNS 使用 FakeIP 解析

这俩似乎并不冲突，而且在这个方案中也已经兼容了，只不过配置是需要修改一下的

@povsister
@bobryjosin

现在这个方案默认是将所有国外 IP 全部送去 FakeDNS 解析，也就是所谓的大陆白名单，但是如果你们的使用场景是有直连需求，那你们的方案应该是黑名单模式。那只把需要代理的地址送去 FakeDNS 解析就好了。

@bobryjosin

我猜你是把 FakeIP 这个操作和 Clash 的 FakeIP 模式绑定到一起了。实际上这两者并没有什么强关联。

Clash 是把所有网络请求全都引入到自身，然后在根据配置，选择 Real-IP 解析模式或者 FakeIP 解析模式。

如果是 Clash 的 FakeIP 解析，会把所有的网址全部解析为 FakeIP ，所以才会有你所谓的入侵性太强的问题，实际上这是 Clash 的问题而不是 FakeIP 的问题。

这套方案 DNS 是先在 PaoPaoDNS 上处理，而 PaoPaoDNS 只有国外(需要代理)的地址，才会送到 Clash 的 FakeIP 解析，其他的地址都是用递归服务器解析到真实 IP 的。而需要代理的地址，真实 IP 并不具备什么意义。如 @yyysuo 所说，只有可达和不可达两种状态。

@ssgooglg
直接路由 Clash 难受就难受在一炸全炸

@nilai

如果这样做，就相当于把对所有 IP 的请求全部导向了旁路网关，这和我们想要的结果(国内外分流)是相违背的。

目前的做法是，设备要访问一个网站，会先向 PaoPaoDNS 请求解析地址，PaoPaoDNS 根据分流规则，分别到递归服务器和 FakeIP 上去解析。如果是国外的应用，会返回 FakeIP 。这样设备就会访问 FakeIP 。由于创建了静态路由表，所以 FakeIP 的请求流向了 PaoPaoGateWay 旁路网关。从而实现经由网关访问对应的网站。

但是 IP 应用由于没有 DNS 这一步，导致网络请求直接从普通网关流出而没有流向旁路网关。

所以需要对其 IP 设置静态路由表。

@yyysuo
如果不屏蔽 NAT ，你在 Clash 里看到的来源 IP 将全部都是路由器的 IP ，这样不利于查看运行信息。

参考
https://github.com/kkkgo/PaoPaoGateWay/discussions/26

@MrLonely

加上了

@Niphor affine 客户端不支持私有部署，我就没试

@SkywalkerJi
确实是没算 AP ，因为很多家庭用主路由自己的无线网就足够了，我买的那个只是因为天线坏了所以没无线。

实际上现在就算是好的同款机器也只要 60 块钱左右了，一直在降价。

如果有其他的比如 MESH 或者 ACAP 的方案需求，那就不在本文的讨论范围内了。