[Bug] connect error: couldn't find ip

[yjiawqgj]

Verify Steps

• [X] Tracker 我已经在 Issue Tracker 中找过我要提出的问题
• [X] Branch 我知道 OpenClash 的 Dev 分支切换开关位于插件设置-版本更新中，或者我会手动下载并安装 Dev 分支的 OpenClash
• [X] Latest 我已经使用最新 Dev 版本测试过，问题依旧存在
• [X] Relevant 我知道 OpenClash 与 内核(Core)、控制面板(Dashboard)、在线订阅转换(Subconverter)等项目之间无直接关系，仅相互调用
• [X] Definite 这确实是 OpenClash 出现的问题
• [ ] Contributors 我有能力协助 OpenClash 开发并解决此问题
• [ ] Meaningless 我提交的是无意义的催促更新或修复请求

OpenClash Version

0.45.164

Bug on Environment

Lean

OpenWrt Version

23.346.45702-3e8eb4a

Bug on Platform

Linux-amd64(x86-64)

Describe the Bug

查询内核debug日志全部显示connect error: couldn't find ip。从不支持的hy2协议切换dve分支后，就正常了两天，第三天晚上就开始频繁掉线，第四天白天还好，晚上又是频繁掉线，节点状态一会全部红 一会这几个红 一会那几个红 一分钟能变好几次。今天白天更是99%时间连接不上。有时候只能打开网页，后续连接就又不行了。就是这么快就掉线了。同一机场配置使用hiddify next却没有问题。

To Reproduce

查询内核debug日志全部显示connect error: couldn't find ip。从不支持的hy2协议切换dve分支后，就正常了两天，第三天晚上就开始频繁掉线，第四天白天还好，晚上又是频繁掉线，节点状态一会全部红 一会这几个红 一会那几个红 一分钟能变好几次。今天白天更是99%时间连接不上。有时候只能打开网页，后续连接就又不行了。就是这么快就掉线了。同一机场配置使用hiddify next却没有问题。

OpenClash Log

已在其它附件中上传！

OpenClash Config

No response

Expected Behavior

^^

Additional Context

调试日志.txt

[yellowsavant]

passwall先关掉吧，iptables里都是它的遗迹.....

[ghost]

passwall先关掉吧，iptables里都是它的遗迹.....

clash未运行，所以题主应该是clash上不了网切pw然后生成的日志。。。

---

我发表一下看法啊 正常了两天 节点状态一会全部红 connect error 这些都表明这其实是节点连通状态的问题，我没用过hiddify next，但clash有个机制，同一个节点连续连通失败5次就会触发healthcheck，然后有机场会ban频繁针对所有节点连通性测试，然后又因为urltest发现节点连通性测试被ban，触发healthcheck，urltest。。。。。。。 解决方法也简单，只要出问题时确定节点真没问题的情况下切select就好

文字看着有点绕，简单画了个图

graph TD;
    节点不通节点变红-->urltest连接了不通的节点
    urltest连接了不通的节点-->触发healthcheck
    触发healthcheck-->机场发现大量healthcheck
    机场发现大量healthcheck-->阻止超过阈值部分的连接
   阻止超过阈值部分的连接-->节点不通节点变红

---

再多嘴一句啊 你用aria2.sh脚本安装了aria，发现下种子不如transmission或qbt，你去找aria2也不该来找aria2.sh的问题呀 XD

[yjiawqgj]

passwall先关掉吧，iptables里都是它的遗迹.....

我在发现clash无法使用hy2协议后中间使用了passwall一天左右的时间，后来我在issue里搜索时发现clash更新dev分支内核后，就把passwall给关闭了，然后使用dev分支的内核，但这次你说和passwall有关，基于我确实使用它了，就查看它，主开关是关闭状态。也就是没有使用它。我该如何安全清理iptables或者passwall？

[yellowsavant]

passwall先关掉吧，iptables里都是它的遗迹.....

我在发现clash无法使用hy2协议后中间使用了passwall一天左右的时间，后来我在issue里搜索时发现clash更新dev分支内核后，就把passwall给关闭了，然后使用dev分支的内核，但这次你说和passwall有关，基于我确实使用它了，就查看它，主开关是关闭状态。也就是没有使用它。我该如何安全清理iptables或者passwall？

我对passwall不是很熟，仅仅是看到你的iptables有passwall相关的命令行，一般科学插件之间没有兼容性，同时间只能有一款科学插件运行，在你关闭passwall后，不妨重启下设备让环境复位下 如果不重启机器，可以简单重启防火墙复位下防火墙规则，应该也能清掉多余的iptables规则（或者说尸体，遗迹） 你可以在ssh命令行里下这个命令：service firewall restart，也可以检查下 /etc/config/firewall 把一些非必要的规则先注解掉 另外据我的经验，openwrt的内核不需要太新，新的内核常常会有一些不可名状的bug，向下兼容性也不好 上面的兄弟说的有道理，太频繁的连线检查会触发机场阻断攻击保护，你可以先关掉相关的选项再行测试 如果再次无法连接，可以ping一下机场IP以确定是否为网络连线问题，抑或是触发机场保护机制，好确定是谁的问题 若你想移除passwall，可以使用命令行的opkg remove命令或是web介面里的系统==》软件，的移除功能 要是你的机场常有连线问题（一些不靠谱的机场是会有这个问题）要么换机场，要么可以做一个round-robin节点组把状态较好的节点扔到这个节点组（记得需要改规则匹配）也能避免机场保护机制触发 暂时先想到这些，Good luck！

[yjiawqgj]

passwall先关掉吧，iptables里都是它的遗迹.....

我在发现clash无法使用hy2协议后中间使用了passwall一天左右的时间，后来我在issue里搜索时发现clash更新dev分支内核后，就把passwall给关闭了，然后使用dev分支的内核，但这次你说和passwall有关，基于我确实使用它了，就查看它，主开关是关闭状态。也就是没有使用它。我该如何安全清理iptables或者passwall？

我对passwall不是很熟，仅仅是看到你的iptables有passwall相关的命令行，一般科学插件之间没有兼容性，同时间只能有一款科学插件运行，在你关闭passwall后，不妨重启下设备让环境复位下 如果不重启机器，可以简单重启防火墙复位下防火墙规则，应该也能清掉多余的iptables规则（或者说尸体，遗迹） 你可以在ssh命令行里下这个命令：service firewall restart，也可以检查下 /etc/config/firewall 把一些非必要的规则先注解掉 另外据我的经验，openwrt的内核不需要太新，新的内核常常会有一些不可名状的bug，向下兼容性也不好 上面的兄弟说的有道理，太频繁的连线检查会触发机场阻断攻击保护，你可以先关掉相关的选项再行测试 如果再次无法连接，可以ping一下机场IP以确定是否为网络连线问题，抑或是触发机场保护机制，好确定是谁的问题 若你想移除passwall，可以使用命令行的opkg remove命令或是web介面里的系统==》软件，的移除功能 要是你的机场常有连线问题（一些不靠谱的机场是会有这个问题）要么换机场，要么可以做一个round-robin节点组把状态较好的节点扔到这个节点组（记得需要改规则匹配）也能避免机场保护机制触发 暂时先想到这些，Good luck！

谢谢你的帮助。机场应该没有问题，也没有触发什么阈值。如果触发的话我在短时间使用其它软件也应该无法连接。我先尝试使用命令重启防火墙，实在不行就重新安装。

[ghost]

你可能把我说的误会成防ddos这类的机制了

真事啊。我之前一个机场，恰逢m核延迟存储有bug，m核那边issue都在，虽然不是这个号发的。我查日志平均2秒一次健康检查，基本前一次都没全部完成新的一次就开始了，体感就是你这情况，节点状态红白来回变，我赶紧换的p核用了一段时间等bug修了。之后向机场老板自爆才问出来的，按老板的意思是防负载均衡，有人拿机场搞跳板。

现在机场基本都是国内服务器不同端口号做中转，老板就搞了个ip每a秒以内连接b个端口c次，就禁止新请求响应，a就十秒以内，b和c设个上百，用户正常用根本触发不了。然后一搞这种健康检查，比如10秒连了10个节点，第11个就不让用了显示超时，然后第1个测速完成，断开了，第12个又可以连了。。。这就是一会儿白一会儿红。 然后urltest比如连的第4个，然后第16个测时第4个正好没数据，第4个就被断开了，urltest连4，无法连通，第12个刚才有数据，切过去，同时发起新的健康检查，然后12比如为了30又断了。。。

这么说能理解不，正常如果设置几秒内上百个，真就只有极端情况才能触发，你换个软件同时用最多也只会感觉网卡，因为没过几毫秒就有端口被释放，你的软件就趁机连接上了，然后再断，再连。。。

所以切非自动组，不触发健康检查，等这些已触发的批量健康检查完成就好了

---

再说一个会触发类似情况的，题主不存在，但反正说到这种情况了，顺便说一下，铺个路 自己码配置文件时，rules和dns的代理组不要为了省事直接指向自动组，通过一个select中转一下。否则也会触发频繁的健康检查

proxy-groups:
- {name: A, type: url-test/fallback/load-balance...
rules:
- DOMAIN-SUFFIX,google.com,A
- DOMAIN-SUFFIX,twitter.com,A
dns:
 nameserver:
  - https://dns.cloudflare.com/dns-query#A

一定要转一下

proxy-groups:
- {name: A, type: select, proxies: [B...
- {name: B, type: url-test/fallback/load-balance...
rules:
- DOMAIN-SUFFIX,google.com,A
- DOMAIN-SUFFIX,twitter.com,A
dns:
 nameserver:
  - https://dns.cloudflare.com/dns-query#A

---

另外，多嘴一句，我看你的用词，好像把dev核搞错了。。。 openclash的dev确实是好的，但内核可不是。正好你在找能用hy2的内核，所以要是没啥特殊想法的话换m核吧，还能把dns代理上，减少dns类错误。

[yellowsavant]

你可能把我说的误会成防ddos这类的机制了

真事啊。我之前一个机场，恰逢m核延迟存储有bug，m核那边issue都在，虽然不是这个号发的。我查日志平均2秒一次健康检查，基本前一次都没全部完成新的一次就开始了，体感就是你这情况，节点状态红白来回变，我赶紧换的p核用了一段时间等bug修了。之后向机场老板自爆才问出来的，按老板的意思是防负载均衡，有人拿机场搞跳板。

现在机场基本都是国内服务器不同端口号做中转，老板就搞了个ip每a秒以内连接b个端口c次，就禁止新请求响应，a就十秒以内，b和c设个上百，用户正常用根本触发不了。然后一搞这种健康检查，比如10秒连了10个节点，第11个就不让用了显示超时，然后第1个测速完成，断开了，第12个又可以连了。。。这就是一会儿白一会儿红。 然后urltest比如连的第4个，然后第16个测时第4个正好没数据，第4个就被断开了，urltest连4，无法连通，第12个刚才有数据，切过去，同时发起新的健康检查，然后12比如为了30又断了。。。

这么说能理解不，正常如果设置几秒内上百个，真就只有极端情况才能触发，你换个软件同时用最多也只会感觉网卡，因为没过几毫秒就有端口被释放，你的软件就趁机连接上了，然后再断，再连。。。

所以切非自动组，不触发健康检查，等这些已触发的批量健康检查完成就好了

另外，多嘴一句，我看你的用词，好像把dev核搞错了。。。 openclash的dev确实是好的，但内核可不是。正好你在找能用hy2的内核，所以要是没啥特殊想法的话换m核吧，还能把dns代理上，减少dns类错误。

不不，我不是说ddos，况且ddos一般是大量不同来源发起SYN服务器触发，和他这个问题不太一样 可能我语法表达上有问题，其实就是connetion burst之类的session audit规则 但是除非一直create new connection，（所以有些机场会封p2p之类的流量）不然一般不会触发这个东西， 机场把这个搞得太死，也会赶跑用户，之前我用过几个机场就是搞得太死，让我直接弃用 况且client端用点load-balance，应该不算过分才是，毕竟那么多节点（ports）放着也是放着，唯一的缺点就是节点切换时会有lag产生 我也跟你讲个真事，我曾经用过的一个机场会在每个端口的一段时间内count你的流量，结果就是浏览某些不可描述的网站或是下载大量content遭到限制，解决的办法就是轮换节点或是换个机场，我个人觉得换机场比较快啦，省得折腾

[ghost]

不不，我不是说ddos，况且ddos一般是大量不同来源发起SYN服务器触发，和他这个问题不太一样 可能我语法表达上有问题，其实就是connetion burst之类的session audit规则 但是除非一直create new connection，（所以有些机场会封p2p之类的流量）不然一般不会触发这个东西， 机场把这个搞得太死，也会赶跑用户，之前我用过几个机场就是搞得太死，让我直接弃用 况且client端用点load-balance，应该不算过分才是，毕竟那么多节点（ports）放着也是放着，唯一的缺点就是节点切换时会有lag产生 我也跟你讲个真事，我曾经用过的一个机场会在每个端口的一段时间内count你的流量，结果就是浏览某些不可描述的网站或是下载大量content遭到限制，解决的办法就是轮换节点或是换个机场，我个人觉得换机场比较快啦，省得折腾

咱俩类似，但我可能更极端一点，我直接关注了个机场花名册，不定时发新机场，我就挑一个搞一个月，新机场刚开人也少所以节点不会太差，一到期我就换。 缺点嘛，就是个人信息泄露比较严重，不过邮箱支付方式全是特意折腾的小小小号，有能力定位到我的也不会通过小小小号查

[yellowsavant]

不不，我不是说ddos，况且ddos一般是大量不同来源发起SYN服务器触发，和他这个问题不太一样 可能我语法表达上有问题，其实就是connetion burst之类的session audit规则 但是除非一直create new connection，（所以有些机场会封p2p之类的流量）不然一般不会触发这个东西， 机场把这个搞得太死，也会赶跑用户，之前我用过几个机场就是搞得太死，让我直接弃用 况且client端用点load-balance，应该不算过分才是，毕竟那么多节点（ports）放着也是放着，唯一的缺点就是节点切换时会有lag产生 我也跟你讲个真事，我曾经用过的一个机场会在每个端口的一段时间内count你的流量，结果就是浏览某些不可描述的网站或是下载大量content遭到限制，解决的办法就是轮换节点或是换个机场，我个人觉得换机场比较快啦，省得折腾

咱俩类似，但我可能更极端一点，我直接关注了个机场花名册，不定时发新机场，我就挑一个搞一个月，新机场刚开人也少所以节点不会太差，一到期我就换。 缺点嘛，就是个人信息泄露比较严重，不过邮箱支付方式全是特意折腾的小小小号，有能力定位到我的也不会通过小小小号查

哈哈必须的，不是吗？至于信息泄露，对于一个喜欢折腾的人来说是不存在的！ by the way，你这个转节点组还挺有意思的，这个我倒没试过，改天玩玩，先谢啦！

[github-actions[bot]]

This issue is stale because it has been open 60 days with no activity. Remove stale label or comment or this will be closed in 5 days