@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 查询。

@hfl1995 #49 打劫~！交出你的固件~😄

OP 绝对不是特工，特工才不会这样宣扬自己~
我知道楼主想我们夸他。楼主真厉害，好棒棒哦。

@ppbaozi #35 对于代理服务器而言，他是根据你访问的域名来本地再解析一次，所以 ipv 几都不重要，重要的是流量是如何发送给 openwrt 。

openwrt 当然可以，但完全没必要啊，现在梯子又不是跑在 L3 的隧道~何必纠结爬墙的流量是否解析到 ipv6 ？只要能让流量跑到梯子的程序里就完成任务了啊。

@SenLief #32 那么就让局域网内的 DNS 指向支持分流的设备上。

@ppbaozi 对于代理服务器而言，他是根据你访问的域名来本地再解析一次，所以 V 几都不重要，重要的是流量是如何发送给梯子。
楼主场景是使用 op 作为旁路由，但其实并非真正网络意义上的旁路由，因为他所有流量依然还是从 openwrt 走。
如果使用路由转发的方法来区分流量，那么他的问题也迎刃而解。
楼主的问题是 V2EX 应该要转发给梯子的，但却解析到了 ipv6 的地址，而代理工具没有工作在 ipv6 的地址上。
那如何才能既不影响使用 ipv6 访问国内站点，又能让爬墙流量乖乖的跑去 openwrt ？
这问题的本质就是分流啊

@SenLief #28 怎么会一样？国内流量直接从主路由出去了，而且普通家庭出国流量肯定比国内流量要小。硬路由国内流量完全就是直出的，硬件转发等性能都是完全的。
如果旁路由是 clash ，你国内流量要先到 clash 过一遍再去主路由。瓶颈就在 clash 了。几百兆可能没啥感觉。如果是 1000Mbps ，过 clash 后有可能就只有 600Mbps ，如果是小包估计就更差了。

@carrionlee 不是策略路由，普通路由表就行 最差的 tplink 固件都支持啊。

@neroxps #22 路由跟踪结果就是这样的。
https://i.imgur.com/p244uG3.png

@hcwhan #20 额~设备一样，但·····感觉完全没必要管出墙流量的 ipv6 啊。https://blog.skk.moe/post/what-happend-to-dns-in-proxy/
不管你获得什么 IP ，最终代理服务器都会从本地再查一次 DNS 。所以只需要 Mikrotik 那边把 fake-ip 转发给 openwrt 即可。
国内流量完全不经过 openwrt 。https://i.imgur.com/xi4QoHN.png

@BaseException #34 哈哈 基础加密就好了，说白了回家那点流量，除非是公司或者保密单位，谁会抓你的包进行解密哦。

@BaseException #33 不过 rust 的版本我没试过。我直接 opkg 装的。

@BaseException #33 原理是一样的，libev 和 rust 写的 server 不都一样的功能吗？

参考 https://www.v2ex.com/t/947704
或者使用 vpn 工具回家，不建议端口映射。


@Ben2022 还记得之前 LastPass 被入侵就是因为管理员家里的 plex 没更新，一直用存在漏洞的版本，导致严重的后果哈~

@SenLief #14 没看懂，你什么路由啊，上游 DNS 基本都能设置的吧？不行你 DHCP 分配的 DNS 是 openwrt 呗。不过这样会存在单点故障。
我的主路由是 Mikrotik ，我写了脚本一直检查 openwrt 的 dns 查询是否正常，如果查询失败，会微信推送给我，并把当前的 DNS 换成运营商的 DNS 。

主路由的 DNS 充当缓存作用。即使 openwrt 炸了也不至于立刻炸。

@SenLief 主路由不支持无所谓啊，你把主路由的上游 dns 改成你的 openwrt 即可啊。

@BrightMars https://github.com/AdguardTeam/AdGuardHome/wiki/Configuration#specifying-upstreams-for-domains

应该是这里指定你的 上游 DNS 服务器是 shellclash 即可。然后 shellclash 使用 fake-ip 方案。shellclash 的 mark 文件里添加
dns_redir=已禁用
dns_no=已禁用
这两个标记。让 shellclash 在 iptables 里挟持 DNS 这样如果 AG 装在同一台 openwrt 上就不影响了。

@x66 github 上好多插件啊，smartdns 甚至用 dnsmasq 也行。

我是用大佬写的 coredns 插件，插件支持订阅网上的 clash yaml 规则。

https://github.com/charleyzhu/coredns_wormhole_plugin

但大佬没有写文档，也没有写 config 范例。得自己看代码咯~

@jdjingdian 也行，但这样就需要一张准确的国内国外路由表。我更喜欢订阅网上的域名规则，根据域名规则直接分流，手机，路由，PC 用同一套规则。