[Bug] R2S 旁路由运行 OpenClash 严重增加局域网内 iPhone 待机耗电 #2614
Comments
akira304moto
changed the title
|
我和你一样，一直有这个情况，我也是 R2S，做的主路由，固件基本都试过，包括原版的 OpenWrt，经过我多次待机测试： 测试设备：iPhone 13 Pro、iPhone XR、iPad Air 4
所以目前只能用的 ShellClash：Redir-host 模式才能正常 |
|
这会是什么问题？神奇，cy一下 |
|
很好奇，关注一下。 |
|
删除 Ad 规则 |
|
不要发布无意义的回复，大家有同样情况的可以将自己的网络环境阐述一下，方便找出问题 |
|
X86也遇到了同样的问题，我今天测试了删除苹果相关规则（之前用的ACL4的苹果规则，规则比较简单没有blackmatrix7全面，且为直连），让苹果走Final（final是走代理），耗电情况应该是正常了。模式为：redir-host，有时间再测试一下fake-ip。 |
|
我没有使用过passwall，想问一下你测试的passwall耗电情况细节问题。passwall设置的是什么分流规则，gfw列表还是绕过中国大陆IP？passwall有无设置苹果规则？如有设置，苹果连接走直连还是代理？ |
你是只把里面 Apple-proxy.list 走代理了。还是整个 Apple.list 全走代理了， |
这两天调mosdns发现个情况，可能跟这个issue相关联。就是32-courier.push.apple.com这类推送相关的长链接域名，DNS拿到的中国IP也会被geoip库识别为非CN IP（geoip用的是Loyalsoldier的）。 这个现象导致的结果是，在Clash的dns机制中，用nameserver组获取的国内IP会被GEO IP识别为非CN，所以抛弃，进而使用fallback获取到位于国外的IP。然后clash策略组大概率会把apple走国内，也就把非CN IP走国内，可能会影响iOS的业务。如果让apple走了final，也就是非CN IP走了final，可能歪打正着解决了这个问题。。 以上只是描述下GEO IP这个坑，不一定是这个issue的成因。 |
我尝试使用blackmatrix7的更为全面的规则，且并未使用fall-back dns查询功能，观察苹果链接。看起来所有苹果域名以及ip链接都被规则捕获并直连。如果所有苹果链接都被规则捕获，理论上不应存在被geo ip误判的情况，但依然有耗电增加的问题。 |
直接删除苹果相关所有规则，苹果的域名链接让clash查询dns，用ip判断是走geo ip cn（直连）还是final（代理），苹果的ip链接也是如此。 |
|
可以试试让所有会保持长连接的地址绕过内核，我的小米手机也出现了待机耗电异常的情况，发现待机时持续未知原因的唤醒，再将Google FCM和小米push绕过内核后，情况立刻消失 |
@LovelyToaster 请问mipush绕过内核走的是IP白名单吗？ 网上没找到mipush的ip段，可否提供下？ update: 好像不需要，直接所有china ip都绕内核就好了；只有apple和fcm的国外ip段需要单独处理 |
确实，我是直接china ip都绕过内核，然后fcm单独处理 |
其实好像是只要走内核的连接都会造成我的手机唤醒耗电，我把mipush和FCM绕过内核让情况消失的前提是我对于手机的大部分应用回到后台后链接会被关闭，而且中国ip段绕过内核 |
刚才发现了这个issue：v2ray/v2ray-core#2564 结合你的现象，猜测应该是golang的这个15秒interval的问题（clash内核也是go写的）；至于是不是本issue的成因，还需要再测测。（如果是，可能也不是这个repo能解决的了） |
|
关联一个clash的issue：https://github.com/Dreamacro/clash/issues/996 |
按照这个issue 我自编译了一个内核，发现唤醒确实恢复正常了，耗电情况时间太短不确定 |
关注下，我也是Redir-host模式下把apple相关域名设置直连之后，包括32-courier.push.apple.com，apple-dns.net之类的，晚上待机耗电加快 |
|
更换GEOIP能否解决？另外苹果商店的软件下载明显变慢，比不用软路由慢的多 |
我也是订阅转换用的ACL4的,然后切换mate模式在规则集与策略组管理里加上的blackmatrix7的，应该是这样操作的吧？ |
|
我给clash加长了keep-alive心跳间隔时长（默认是15s），并经过吃灰iPad一个多月的待机验证，观测到待机耗电确实是在减少了。至少对我来说clash的续航问题应该是这个issue导致的。 我的解决方案是在Clash.Meta上简单修改了一下keep-alive的心跳间隔：cubarco/Clash.Meta@e5a0e6c 。有异常耗电问题的朋友可以尝试下，release里面有预编译的binary。 |
感谢大佬！我不严谨的测试了几天，耗电情况确实有改善。赞！ |
|
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 |
|
up |
|
我也遇到了类似的问题，我手机使用passwall 时待机基本走横线，不掉电，或者很少的电，使用open clash 后，晚上7个小时基本掉电20%+，其他用着很舒服，这点是真难受😁 |
|
参考这个 issue golang/go/issues/48622 ，具体原因应该如下：
|
This is just a quick hack way to address the battery draining issue. See details from the following issues: https://github.com/Dreamacro/clash/issues/2867 vernesong/OpenClash#2614
|
由于目前官方 Clash 团队还没有关注这个 https://github.com/Dreamacro/clash/issues/2867 ，所以我直接改了下代码，将 TCP keep alive interval 设为了 1800s。大家可以测试看下，看看是否解决了这个问题： https://github.com/silverzhaojr/clash/releases/tag/v1.18.0-fix-tcp-keep-alive |
@silverzhaojr 你可以在这个issue里面网上翻翻，这个方案我已经提过：cubarco/Clash.Meta@e5a0e6c ，而且验证是有效的。 |
我就是看了你这个代码做的改动🤣。这里主要是基于 Clash 的最新版本编译了下带有修复的代码，方便其他遇到这个问题的人暂时用着。 |
@cubarco 能否给 meta 提个 pull request 修复一下 |
提高keep alive时间好像会导致部分连接不会断开，我改成3600后连接数经常200+，而且可以看见有很多相同连接存在几个小时，即使发出连接的设备已经关机，连接依旧存在 |
这个是预期的行为，上面有解释：#2614 (comment) 。改成 30min 后，无效连接最多会存在 30min + 30min * 9 = 5hr。 最佳做法是等 Go 语言支持分开设置 KEEP_IDLE, KEEP_ALIVE_INTERVAL，KEEP_COUNT。 |
大佬能不能给一个meta版本的tun模式的内核编译成品呢 |
MetaCubeX/mihomo#715 (comment) 貌似meta内核有大佬添加了配置，但是我不会配置。 |
根据这里的改动，应该是在 clash meta config.yaml 配置文件中增加一行： 将 注意要用这里的 alpha 版本：https://github.com/MetaCubeX/Clash.Meta/releases/tag/Prerelease-Alpha |
|
在openclash中如何设置呢。 |
|
最新版的内核还没有修复这个问题吗？ |
最新的alpha已经可以正常配置tcpalive时间了 |
|
我的iPhone和iPad一样的现象，连家里的Wi-Fi待机比蜂窝待机还要耗电多了。把OpenClash关掉，待机就正常了。。。 现在的临时解决方案：在OpenClash的黑白名单里添加了iPhone和iPad，不让它们走OpenClash了，它们出国用小火箭app代替。。。 这个问题OpenClash什么时候能给予解决啊 |
我测试了下，openclash 0.4.151-beta里已经有相关选项可以调整tcp keep-alive 间隔了 |
现在这个链接没了。 |
|
我的解决方案是在绕过核心的大陆IP段中加入APNS的IP段，实测Redir-Host 模式下可以绕过核心。APNS的具体ip段见https://support.apple.com/zh-cn/102266 |
|
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 |
|
最近我也在研究这个事情。发现把TCP Keep-alive时间间隔调成了1800s后，虽然在大部份网站不会有问题，因为大部份网站在关闭后就会自动在OpenClash里关闭掉已建立的连接。而比较特殊的网站，比如下面所说的 具体复现步骤：
在把OpenClash的设置改回TCP Keep-alive为默认值的15s后，由于只需要300s就可以关闭无效连接，所以即使等个10~20min，旧的连接也已经被OpenClash给清掉了；而在还保留着旧连接的300s内重新访问网站时，旧的连接也依旧有效，所以不会出现无法访问的尴尬情况。 至于移动设备的长连接该怎么处理，我是苹果设备，使用了john5du的方法，实测苹果的推送连接不再经过OpenClash的内核了。 |
苹果有统一推送了，但是安卓上的长链接就多了去了，不可能一个个设置的。话说这个选项的默认值是多少？ |
15s，安卓fcm排除，然后再把cn ip排除，耗电就可以下降到忽略的地步 |
走direct策略是排除吗？ 如果不是，那么如何在config.yaml里面实现排除cn ip呢？ |
控制 Clash 发出 TCP Keep Alive 包的间隔，减少移动设备耗电问题的临时措施。单位为秒 此时 Clash 发现并关闭一个无效 TCP 连接用时： 1*keep-alive-interval + 9*keep-alive-interval vernesong/OpenClash#2614
and others
Verify Steps
OpenClash Version
v0.45.47-beta
Bug on Environment
Official OpenWrt
Bug on Platform
Linux-armv8
To Reproduce
只需查看iPhone电量消耗即可
Describe the Bug
R2S 作为旁路由，由 TP-LINK 主路由的 DHCP 为连接的设备下发网关/DNS 指向它。官方 openwrt 22.03-rc5 固件，运行 openclash 会导致 iPhone 待机时耗电急剧增加。
尝试切换 redir-host/fake-ip 模式、开关旁路由模式、开关 DNS 劫持、切换 meta/TUN 核等操作，均未改变耗电增加的情况。
查看 iOS 设置中的“App 隐私报告”，待机时段没有异常连接。使用 AdGuard Home 记录，待机时应只连接过 iCloud 和推送通知服务器，无异常情况。
而关闭 openclash 后，使用 passwall 或直连，待机耗电均恢复正常水平。排除路由器 Wi-Fi 设置原因。
另外试过关闭 openclash 后，在手机本机运行 shadowrocket 和 stash，耗电只比正常多一点，远达不到 openclash 的情况，因此排除 clash 的原因。
OpenClash Log
OpenClash 调试日志
生成时间: 2022-08-08 08:20:59
插件版本: v0.45.47-beta
隐私提示: 上传此日志前请注意检查、屏蔽公网IP、节点、密码等相关敏感信息
OpenClash Config
No response
Expected Behavior
待机耗电恢复正常水平
Screenshots
以下测试在一台 iPhone 7 上进行：全程除查看电量外不操作手机，因此 App 电池用量处仅显示“设置”，用量几分钟。
可见使用 PassWall 时待机电量消耗正常；在其他设备操作关闭 PassWall 并开启 OpenClash，会立即影响到手机耗电。
一直开启 OpenClash，电量消耗严重。
关闭 OpenClash，手机本机运行 Stash，电量消耗正常。
The text was updated successfully, but these errors were encountered: