yichya QC
yichya QC
> 3\. 合并为两个链 `XRAY_RULES` 和 `XRAY_PROXY` 。 这个是必须要改嘛，我觉得原来 luci-app-shadowsocks 的那几个链的分工还挺明确的，以及顺便看一下 nftables 的实现是否可以一起做了吧
另外其实，我预期的用法是 * Secure DNS 和 Default DNS 填一个没在 `geoip:cn` 里面的 DNS 比如 8.8.8.8 之类，这些 DNS 请求都会通过 Xray 转发出去 * Fast DNS 预期只用来解析明确不会被污染的域名（默认是 `geosite:cn`） 这两种情况都不需要 DoH，而且也都比 DoH 要快。 当然 DoH 的支持已经在...
> So, 我重新编译 ipk 就可以了? 等下我提一下版本号，因为最近在考虑顺便加点东西所以给忘了（太忙了。。。）
> 现在可以了? 嗯，可以了
看了一下，DoH 的配置还有些问题，会各种影响 iptables 和 dnsmasq 的行为。#69 先回滚掉了，后面再认真考虑一下怎么做
> 刚刚测试最新版的master分支编译，依然存在这个问题 确实，还没修 > 我openwrt上运行了个vpn服务器，一启动xray，从wan入站的vpn连接就断了 > > 但是我发现在bypass上添加wan端的ip后，那个ip过来的包就可以正常入站了，感觉是因为入站流量被重定向了？ 这么做确实能绕过这个问题，但其实比较建议写一个匹配设备和端口的规则 return，或者 cherry-pick 一下 #51 > 不太熟iptables，特别是tproxy，完全不知道怎么整... 看了半天防火墙规则，没看懂，加了bypass之后好像是在ipset里面加了个对应的ip，然后iptables匹配上之后直接return了。难道是wan进来的流量也被重定向到xray去处理了？ tproxy 用的是 mangle 表，mangle 确实是这样的，原理其实我也不是完全理解（
虽然我觉得你的用法并不是最佳的（之前有提过，比较推荐的做法是 Fast DNS 写一个 114.114.114.114 这种国内的，Secure 和 Default 写 8.8.8.8 这种海外的，然后海外 DNS 请求实际都会被 Xray 转发出去，也就不存在明文发送被 GFW 抢答的问题）。。。 如果只是想改 Hosts 的话，自己改一下 dnsmasq 的配置  但对这个 luci 来说其实也是有必要做的，方法大概会是启动的时候顺便改一下 dnsmasq 的配置，最近太忙了，后面搞搞看
> 3. 重度科学上网环境下，114.114.114.114 会稳定运行一段时间，然后这个 DNS 就废了。 你说的「废了」是指什么现象？
> 不过， Fast DNS 现在目测填入 DoH 地址，就无法连接 internet。 > 所以我另外自配的这台 DNS Server 没开启 DoH，而是采用 UDP IP 模式。 之前直接合了的那个 #69 还是有些问题的，因为 Fast DNS 和 Default DNS 涉及到 Xray 之外的配置（比如 Fast DNS...