deuteros-gex

> @vernesong 请问OpenClash对解析返回记录的TTL默认是多少，这个TTL是否可以修改？ openclash只是帮你创建一层透明代理环境、做一些前置分流而已，它控制不了clash内核的dns ttl。 或者说clash本身也没开放dns ttl给你调，最接近的也只有一个 ``` profile: store-fakeip: true ``` 的参数

> 真的居然和我的想法一模一样，比我早很多，同样的情况，家里的主路由是TPLINK，因为用了TP的AP，所以不方便更换主路由，而且旁路由不稳定，家里人也不喜欢随时断网，这时候所有设备指向主路由就很关键了，旁路由只负责DNS，就算挂了，DNS缓存也能支持一段时间。 > > 我的想法有一点点不同，不是必须 **"在fake-ip-filter里面塞一整个列表"** ，其实还有个办法就是"预代理"，基本就是CLASH的代理过程，过程如下所示，本人基本是个小白，如果有不正确的地方请指出： > > 1. 7874端口获取dns请求之后，直接先进行域名规则匹配（黑名单，IP规则先no-resolve），这部分规则其实就是用户设置的clash规则集&脚本，黑名单命中直接返回fake-ip > 2. 如果1未命中，再匹配域名白名单，如果域名白名单命中，clash使用本地DNS服务直接进行最快的进行resolve，返回真实IP > 3. 如果2未命中，但是用户设置了IP规则，则clash使用本地DNS服务直接进行最快的resolve，结果再进行IP规则匹配，IP匹配命中无需代理则直接返回resolve结果，需要代理则返回fake-ip > 4. 最后最终返回结果是fake-ip，clash直接把连接请求发到远端服务器即可 > > 我觉得这样操作应该不会带来额外开销，无论是返回真实IP还是fakeip，只是相当于多加了一个开关，不至于对性能延迟造成太大影响 -- **即在规则匹配的过程中去做判断返回真实IP还是fakeip，而不是重新做另一套DNS的判断。 也就是需要代理才返回fake-ip，无需代理返回真实IP。用户如果需要国内DNS分流，直接把geoip:cn规则放到自己的规则集中即可，如果不喜欢，可以关掉开关，或者全程不设置IP规则，依然和以前一样，使用fake-ip** > > 我有把这个QA发送到了OPENCLASH，可能和这边的描述存在一点点出入，具体的链接如下： [vernesong/OpenClash#3693](https://github.com/vernesong/OpenClash/issues/3693)...

> > 打了这么多字还反复修改过，说明不是来恶搞的，只是缺乏常识。你可能觉得： > > > dns分流时直接复用rules部分的功能就行，为什么要另做一套？这样后续rules说不定都不用再匹配了 > > > 这个逻辑非常顺滑，应该连代码都不用改太多，用户的配置文件也不需要大改 > > > > > > 但这并不行。 哪怕采用了@benyfu911给出的commit，rules还是得写两套，dns分流和网络分流还是得分开做。 想不到什么特别言简意赅的方式给你解释，只能建议找点网络、dns相关的科班教程看看。 > > 感谢指正，这一思路的源头在passwall2的远程DNS配置中，上面写了一句话，类似的意思是“fakedns：在需要经过代理的时候使用”，于是想着能不能融合使用。我后面去看了V2ray-core和Xray-core的doc，发现他们的fakedns好像也是在配置文件中单独指定分流规则的....并没有融合一说..他们的配置如下 `{ "servers": [ { "address": "fakedns", "domains":...

> > > > 我7621用xray一点问题没有 > > > > > > > > > 这就奇怪了。你也是编译最新版本的lede和helloworld吗？能否把config文件发我参考下，谢谢！ > > > > > > [config.txt](https://github.com/fw876/helloworld/files/11538784/config.txt) helloworld最新代码编译的，基本就默认，application只保留ssr，内核选xray > > 会不会是你用的是ss协议，没用v2ray？我用ss节点的话性能占用也不高 那不然呢。。 v2ray作为一个纯二进制可执行文件的客户端，没有什么额外开销，轻得不能再轻了。 高负载是vmess/vless这些协议造成的，你最开始的描述就有点问题，所以人家才会错意的。

哦，又是这个问题是吧。#3287 #3379 #2791 会报这个错的脚本有好几个，仅凭你给的信息定位不了问题，你得提供稳定复现的方法。 多观察观察这些日志什么情况下会出现，找出点规律再说，否则就只能等作者哪天灵光乍现了。 因为openclash现有的代码套娃套太多次了，一般没人愿意去做正向检查。 你可能觉得给个开关就行，但设计上这些功能从来都是只能手动触发的，并不是自动的。

因为tproxy和tun支持udp，所以redirect就能支持吗？

duplicate of #3188 > Tun内核版本: 2022.06.19-13-ga45638d > Dev内核版本: v1.11.0-7-g5497ada 先尝试更新内核版本吧，现在的太旧了。

https://github.com/Dreamacro/clash/releases https://github.com/Dreamacro/clash/releases/tag/premium

> > https://github.com/Dreamacro/clash/releases https://github.com/Dreamacro/clash/releases/tag/premium > > 再请问一下，这里的内核是不是只需要下载premium就可以，premium包含了tun的功能？ tun是早期叫法，现在上游改叫premium了，但openclash一直沿用了tun的叫法。

> > 同样是升级45.121后内核崩溃，据我观察好像是内存申请的问题，原来旧版本内存一般就几十M，升级后一启动内存就不断申请变大，CPU负载很高，然后就崩溃了。现在回退到45.112后一晚上没出现这个问题。 > > 请问用的是哪个内核（/etc/openclash/core/clash, /etc/openclash/core/clash_tun）版本，我也出现了同样的情况，回退opeclash后依旧 #3188 的问题我自己最后只是靠`换官方openwrt固件、只装需要的包`这种和稀泥的方式绕开了，也不算正面解决。 讲真，个人感觉这就不算openclash的问题了，毕竟是内核在报错。 可以带着你的配置文件和错误日志，到上游项目里去问问看，模仿Dreamacro/clash#2524