楼中楼能否添加一个临时关闭按钮。有时候一些帖子我希望看到最新的回复，但如果是楼中楼开启的话。最新回复我就找不到。

openwrt 的插件 shell 脚本又臭又长。还有可能和其他插件冲突，出了问题重装了如果步骤一样，插件一样，也可能导致问题。还是要看插件实现原理，看插件代码，通过 iptables -S 等查看防火墙规则，软件原理啥的才能排查出问题。还需要理解代理工具的运行原理。
单纯几句话，很难知道到底是什么问题导致的。

@redial39 #62 那你可以用策略路由啊，源地址是 过墙 vlan 目的是 fake-ip 。
打标记也不是不行，但记得在最前面规则做 Fast Forward （ fasttrack connection ） 否则会影响转发性能。

@ericww 哈，我用 shellclash 主要 为了他有 web UI ，能手机临时切节点

@redial39 #50 我以前是打标机的，后来发现不需要打标记，直接用路由表更高效。

https://i.imgur.com/jZE2GrI.png

@redial39
1 、ROS 的 dns 配置是 coredns ，coredns 上游有两个，一个是运营商的 dns ，一个是 clash 的 dns 。coredns 的插件有读取网上的规则。我用的是这个 https://github.com/blackmatrix7/ios_rule_script/tree/master/rule/Clash ，当匹配到 proxy 规则的话就从 clash 查询 dns ，不匹配就从运营商 DNS 查询。（这里也可以配成 smartdns 再做测速返回最优 IP 也可以）

2 、ros dns 只配置一个，我是写了一个 Mikrotik 来解决当 dns 服务器炸了之后，把 ros 的上游 dns 切会运营商 DNS 。https://github.com/neroxps/RouterOS-Script/blob/master/Clash_dns_check.rsc

3 、我上面 1 里说了。我用的 coredns 插件支持各种网上的规则文件，dnsmasq 的 ag 的 clash 的 自动更新订阅。https://github.com/charleyzhu/coredns_wormhole_plugin

@SenLief #44 但国内流量不走旁路由啊。你也可以用一个 arm 盒子或者一个巴掌大的路由跑一个 DNS 这样这种 DNS 炸的几率就小很多了。例如 GL.iNet 的 GL-MT300N-V2 那种巴掌大的。单独跑一个 dns 卓卓有余

把手机爬墙工具的 vpn 关掉就可以了

@hfl1995 #75 谢谢大哥，Starred

@neroxps #41
2 、既然不需要管爬墙流量是否需要解析到 ipv6 。那么我们只需要确保国内的 ipv6 地址能解析到准确的地址，并准确的转发出去即可

@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