@ppbaozi #39 我知道你说的意思，大家都解析到准确的 IP ，然后通过准确的路由去到目的地。
但我的意思是爬墙的流量根本不需要解析真实 IP 。
请看这篇文章。https://blog.skk.moe/post/what-happend-to-dns-in-proxy/

既然不需要解析到准确的 IP 。那么就也不需要解析到 ipv6 地址。那使用旁路由方案的话，就可以让主路由根据路由表转发 fake-ip 给 openwrt 即可。

因为根本不需要考虑 ipv6 是否能过墙，因为代理工具只需要将流量转发给梯子服务器，服务器会根据目的地解析最终的 ip 地址。

```
Fake IP 的定义出自 RFC3089 。这个 RFC 定义了一种新的将 TCP 连接封装成 SOCKS 协议的方法。

浏览器自己都有 DNS 缓存机制，因此浏览器会先开始寻找自己的缓存，不过并没有找到 blog.skk.moe 的解析结果
浏览器通过调用操作系统的 getaddrinfo 方法，向操作系统寻求解析结果
操作系统自己也有一层 DNS 缓存，但是现在操作系统从自己的缓存中依然找不到这一结果
在系统的网络设置之中设置了一个专门的上游 DNS 地址，可能是用户手动设置的也可能是代理客户端设置的。不论如何，这个设置最终会使操作系统向代理客户端发起 DNS 请求
操作系统发出的 DNS 解析请求会经过代理客户端并最终被截获
代理客户端从解析请求中获得域名，从 Fake IP 池中选取一个 IP 建立映射
代理客户端将这个 Fake IP 返回回去，操作系统拿到了这个 Fake IP 并返回给浏览器
浏览器对 Fake IP 建立一个 TCP 连接并发送出去
这个 TCP 连接被代理客户端截获。代理客户端抽取出 Fake IP 并反查出这个 TCP 连接中对应的域名
有了 TCP 连接和域名，代理客户端可以轻易地将其使用 SOSCKS5 或者 某种协议 进行封装
有了 Fake IP ，代理客户端无需进行 DNS 解析。最后不论是浏览器、代理客户端还是远端服务器都不会去和 Fake IP 进行连接，因为在代理客户端这里就已经完成了截获、重新封装。
---------------------
本文著作权归作者 Sukka 所有。本文采用 CC BY-NC-SA 4.0 许可协议，商业转载请联系作者获得授权，非商业转载请注明出处。
作者：Sukka
来源：浅谈在代理环境中的 DNS 解析行为
链接： https://blog.skk.moe/post/what-happend-to-dns-in-proxy/
```

但是使用了 fake-ip 方案后，导致所有的 DNS 都拿到假的 IP 地址，所以就需要 DNS 分流来解决这个问题。

当然，如果用回 openwrt 当主路由，然后配置好支持 ipv6 访问，那么当然也能解决问题。但这 OP 不是说 openwrt 不知道何种原因影响了 PT 和 PCDN 吗，不是所有人都看得懂 openwrt 那个又臭又长的 iptables 规则链的。openwrt 自己的插件本身也有很多插件之间的兼容问题。所以很多人会采用硬路由转发到 openwrt 旁路由的方案来解决稳定性问题。

所以才有了我所说的 DNS 分流。

1 、不需要管爬墙的流量是否能解析到 ipv6 地址，因为现在爬墙的代理过程根本不在乎你拿到什么 IP 地址。他们是根据你的访问域名发送给梯子服务器，再由梯子服务器发起链接给目的服务器的。
2 、既然需要管爬墙流量是否需要解析到 ipv6 。那么我们只需要确保国内的 ipv6 地址能解析到准确的地址，并准确的转发出去即可。
3 、这种方案在旁路由拓扑中，开销是最小的。DNS 开销小，路由转发路径小。传统的旁路由方案其实就是二级路由或者 dhcp 把个别机器配成二级路由，这些方案都不方便管理。
4 、方案的缺点就是 DNS 可能存在单点故障，需要额外的监控脚本来修改主路由的上游 DNS ，如果 DNS 炸了，将会影响整个网络的 DNS 查询。