最新版本日志出现：【/tmp/openclash_last_version】下载失败

sachikomakino commented 1 year ago

Verify Steps

[X] Tracker 我已经在 Issue Tracker 中找过我要提出的问题
[X] Latest 我已经使用最新 Dev 版本测试过，问题依旧存在
[X] Core 这是 OpenClash 存在的问题，并非我所使用的 Clash 或 Meta 等内核的特定问题
[X] Meaningful 我提交的不是无意义的催促更新或修复请求

OpenClash Version

v0.45.70-beta

Bug on Environment

Official OpenWrt

Bug on Platform

Linux-amd64(x86-64)

To Reproduce

启动后每过一段时间日志就会出现报错

Describe the Bug

刚更新完最新版本出现以上的提示，链接好像暂时没问题，请问大神这个错误是什么意思，需要如何修复。

OpenClash Log

2022-11-07 10:12:13【/tmp/clash_last_version】下载失败：【how to fix it, please visit the web page mentioned above.】 2022-11-07 10:12:13【/tmp/clash_last_version】下载失败：【establish a secure connection to it. To learn more about this situation and】 2022-11-07 10:12:13【/tmp/clash_last_version】下载失败：【curl failed to verify the legitimacy of the server and therefore could not】 2022-11-07 10:12:13【/tmp/clash_last_version】下载失败：【】 2022-11-07 10:12:13【/tmp/clash_last_version】下载失败：【More details here: https://curl.se/docs/sslcerts.html】 2022-11-07 10:12:13【/tmp/clash_last_version】下载失败：【curl: (60) Cert verify failed: BADCERT_CN_MISMATCH】 2022-11-07 10:10:57【/tmp/openclash_last_version】下载失败：【how to fix it, please visit the web page mentioned above.】 2022-11-07 10:10:57【/tmp/openclash_last_version】下载失败：【establish a secure connection to it. To learn more about this situation and】 2022-11-07 10:10:57【/tmp/openclash_last_version】下载失败：【curl failed to verify the legitimacy of the server and therefore could not】 2022-11-07 10:10:57【/tmp/openclash_last_version】下载失败：【】 2022-11-07 10:10:57【/tmp/openclash_last_version】下载失败：【More details here: https://curl.se/docs/sslcerts.html】 2022-11-07 10:10:57【/tmp/openclash_last_version】下载失败：【curl: (60) Cert verify failed: BADCERT_CN_MISMATCH】 2022-11-07 09:26:43【/tmp/clash_last_version】下载失败：【how to fix it, please visit the web page mentioned above.】 2022-11-07 09:26:43【/tmp/clash_last_version】下载失败：【establish a secure connection to it. To learn more about this situation and】 2022-11-07 09:26:43【/tmp/clash_last_version】下载失败：【curl failed to verify the legitimacy of the server and therefore could not】 2022-11-07 09:26:43【/tmp/clash_last_version】下载失败：【】 2022-11-07 09:26:43【/tmp/clash_last_version】下载失败：【More details here: https://curl.se/docs/sslcerts.html】 2022-11-07 09:26:43【/tmp/clash_last_version】下载失败：【curl: (60) Cert verify failed: BADCERT_CN_MISMATCH】 2022-11-07 09:26:43 第二步: 组件运行前检查... 2022-11-07 09:26:43 第一步: 获取配置... 2022-11-07 09:26:43 OpenClash 开始启动... 2022-11-07 09:26:43 第六步：删除 OpenClash 残留文件... 2022-11-07 09:26:43 第五步: 重启 Dnsmasq 程序... 2022-11-07 09:26:43 第四步: 关闭 Clash 主程序... 2022-11-07 09:26:43 第三步: 关闭 OpenClash 守护程序... 2022-11-07 09:26:42 第二步: 删除 OpenClash 防火墙规则... 2022-11-07 09:26:42 第一步: 备份当前策略组状态... 2022-11-07 09:26:42 OpenClash 开始关闭... 2022-11-07 09:26:31 OpenClash 更新成功，即将进行重启！

OpenClash Config

No response

Expected Behavior

请问如何修复，谢谢。

Screenshots

No response

amorous-monk commented 1 year ago

好像怎么都解决不了这个问题，头疼。

chenyhd commented 1 year ago

我遇到的问题是无法切换到 tun 模式，下载 clash_tun 失败，应该是都是类似的问题，分享一下我的手动更新方式， :

Plugin Settings -> Version Update -> [TUN] Current Core -> Download

浏览器就会开始下载，会比较慢但是最终会下载成功，上传到服务器然后解压到 etc/openclash/core/clash_tun 目录下，重启 openclash 就可以了

amorous-monk commented 1 year ago

我遇到的问题是无法切换到 tun 模式，下载 clash_tun 失败，应该是都是类似的问题，分享一下我的手动更新方式， :

Plugin Settings -> Version Update -> [TUN] Current Core -> Download

浏览器就会开始下载，会比较慢但是最终会下载成功，上传到服务器然后解压到 etc/openclash/core/clash_tun 目录下，重启 openclash 就可以了

手动下载更新的没有版本号，只有一个大概的创建时间，但创建时间在openclash里又看不出来，这样你就只能靠感觉更新，无法很好的对比版本的新旧。自动更新会检测版本号，对比最新的版本号。

github-actions[bot] commented 1 year ago

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

zzc-tongji commented 1 year ago

出现这个问题的根本原因是 curl 在下载相关的文件时, 连接超时, 一般是因为连接 GitHub 超时,所以你要进行一下判断

本身电脑能否直连 GitHub网站,一般因为域名污染, 都无法直连接,所以推荐在全局设置-->基本设置 中修改 github 地址为另外的地址: 如cdn.jsdelivr.net 2.将 *.jsdelivr.net 加入忽略探测（嗅探）的域名（sni）列表(如果你开启嗅探功能的话) 3.将 - DOMAIN-KEYWORD,jsdelivr.net,DIRECT 加入你的配置文件中, 保证 jsdelivr.net域名一直都是直连

如果执意要从 Github 下载相关文件, 请将 Github 相关域名加入相关代理列表中, 并且保证节点可用, 不然 curl 无法从 GitHub 下载相关文件, 从而报错.(一般都是因为节点无法使用,进而无法下载相关文件报错) 总之是路由器本身网络的问题, 请确保网络正常和节点正常使用的情况下,开启openclash.基本上就不会报错了

@lifetyper 不在 全局设置-->基本设置 ，在 覆写设置-->常规设置。版本：v0.45.141-beta 。

pcloves commented 1 year ago

可以先自己给dnsmsq设置localuse，把dnsmsq作为system resolver，就可以避免路由器自身流量遭遇dns污染了。
uci set dhcp.@dnsmasq[0].localuse="1"
uci commit dhcp
/etc/init.d/dnsmasq restart
参考：#3195

亲测好用，感谢！！！

zyystudio commented 10 months ago

https://cdn.staticaly.com

hunao0221 commented 10 months ago

出现这个问题的根本原因是 curl 在下载相关的文件时, 连接超时, 一般是因为连接 GitHub 超时,所以你要进行一下判断

本身电脑能否直连 GitHub网站,一般因为域名污染, 都无法直连接,所以推荐在全局设置-->基本设置 中修改 github 地址为另外的地址: 如cdn.jsdelivr.net 2.将 *.jsdelivr.net 加入忽略探测（嗅探）的域名（sni）列表(如果你开启嗅探功能的话) 3.将 - DOMAIN-KEYWORD,jsdelivr.net,DIRECT 加入你的配置文件中, 保证 jsdelivr.net域名一直都是直连

如果执意要从 Github 下载相关文件, 请将 Github 相关域名加入相关代理列表中, 并且保证节点可用, 不然 curl 无法从 GitHub 下载相关文件, 从而报错.(一般都是因为节点无法使用,进而无法下载相关文件报错) 总之是路由器本身网络的问题, 请确保网络正常和节点正常使用的情况下,开启openclash.基本上就不会报错了

@lifetyper 不在 全局设置-->基本设置 ，在 覆写设置-->常规设置。版本：v0.45.141-beta 。

Cool. works for me.

thinbug commented 9 months ago

如果是网速慢超时,可以把超时时间设置大一点,能看到下载了一部分. 【/tmp/clash_tun.gz】下载失败：【curl: (28) Operation timed out after 60000 milliseconds with 950364 out of 5674636 bytes received】修改 vi openclash_core.sh 里面的-m 60 改到300

kuloo1234 commented 6 months ago

docker部署的可以检查是否在容器的网络配置中有dns。

cat /etc/config/network

检查是否包含dns选项 config interface 'lan' option type 'bridge' option ifname 'eth0' option proto 'static' option ipaddr '192.168.1.2' option netmask '255.255.255.0' option gateway '192.168.1.1' option dns '114.114.114.114' option ip6assign '60'

我今天的问题是加上dns后解决的。

NewEpoch2020 commented 2 months ago

问题因该就是路由器自身的system dns污染造成的，我这里的情况是这样的：

虽然openclash开启了fake-ip模式，但是路由器本身似乎不会走fake-ip发起请求（似乎和固件有关，有些固件的/etc/resolv.conf不会被dnsmasq修改成127.0.0.1,也就无法走fake-ip模式），而被污染后，raw.githubusercontent.com这个域名在路由器上是解析成0.0.0.0的，这个地址被认为是local地址就直连了，结果当然是访问失败。

所以你在pc或者手机上看似乎github是访问正常的，但路由器本身访问的时候却是被污染的。

基本这都是本地isp才会干的污染，可以看看路由器上/etc/resolv.conf里的nameserver是什么，一般污染就是这个dns服务器干的，一般也就是wan接口接受上游通告dns而获得的本地isp dns或者192.168.1.1这样的光猫地址(也算是光猫作为上游通告过来的dns)。

解决的方法其实就是wan接口不要使用上游通告的dns(最终就是让路由器的system dns至少在访问我们需要的域名时不污染)，我试了下119.29.29.29，223.5.5.5，114.114.114.114这些主流公共dns基本上都不会污染github。

路由器上写死Hosts也是个做法但肯定不太灵活。

因为各地isp dns的污染策略似乎不是很稳定，有时候污染有时候不污染，这就导致了有时候正常有时候出问题。我这里也是最近这两天才出现的。

这个问题解决起来不麻烦。

不过我有点好奇的是，路由器本身流量不走fake-ip模式，而使用路由器的系统dns这个是不是符合设计的预期呢？其实大部分时候路由器本身的流量我们确实不太关心，不过遇到像github这种特例就导致问题了。

要彻底解决的话，是否可以让路由器本身流量像路由器下挂的设备一样也走fake-ip模式呢？就是不知道这样会不会有dns递归死循环的问题。

这里面的回答看了一圈, 还是采用你的回答立竿见影治好了~

vernesong / OpenClash