[Bug] R2S 旁路由运行 OpenClash 严重增加局域网内 iPhone 待机耗电

akira304moto commented 2 years ago

Verify Steps

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

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、节点、密码等相关敏感信息


#===================== 系统信息 =====================#

主机型号: FriendlyElec NanoPi R2S
固件版本: OpenWrt 22.03.0-rc5 r19523-bfd070e7fa
LuCI版本: git-20.074.84698-ead5e81
内核版本: 5.10.127
处理器架构: aarch64_generic

#此项有值时,如不使用IPv6,建议到网络-接口-lan的设置中禁用IPV6的DHCP
IPV6-DHCP: 

#此项结果应仅有配置文件的DNS监听地址
Dnsmasq转发设置: 127.0.0.1#7874

#===================== 依赖检查 =====================#

dnsmasq-full: 已安装
coreutils: 已安装
coreutils-nohup: 已安装
bash: 已安装
curl: 已安装
ca-certificates: 已安装
ipset: 已安装
ip-full: 已安装
iptables-mod-tproxy: 已安装
kmod-ipt-tproxy: 已安装
iptables-mod-extra: 已安装
kmod-ipt-extra: 已安装
libcap: 已安装
libcap-bin: 已安装
ruby: 已安装
ruby-yaml: 已安装
ruby-psych: 已安装
ruby-pstore: 已安装
kmod-tun(TUN模式): 已安装
luci-compat(Luci-19.07): 已安装
kmod-inet-diag(PROCESS-NAME): 未安装
unzip: 已安装

#===================== 内核检查 =====================#

运行状态: 运行中
进程pid: 17653
运行权限: 17653: cap_dac_override,cap_net_bind_service,cap_net_admin,cap_net_raw,cap_sys_ptrace,cap_sys_resource=eip
运行用户: nobody
已选择的架构: linux-armv8

#下方无法显示内核版本号时请确认您的内核版本是否正确或者有无权限
Tun内核版本: 2022.07.07-7-g56f0a92
Tun内核文件: 存在
Tun内核运行权限: 正常

Dev内核版本: v1.11.4-6-gbec4df7
Dev内核文件: 存在
Dev内核运行权限: 正常

Meta内核版本: alpha-g2899a12
Meta内核文件: 存在
Meta内核运行权限: 正常

#===================== 插件设置 =====================#

当前配置文件: /etc/openclash/config/config.yaml
启动配置文件: /etc/openclash/config.yaml
运行模式: fake-ip
默认代理模式: rule
UDP流量转发(tproxy): 启用
DNS劫持: 启用
自定义DNS: 启用
IPV6代理: 停用
IPV6-DNS解析: 停用
禁用Dnsmasq缓存: 启用
自定义规则: 停用
仅允许内网: 启用
仅代理命中规则流量: 停用
仅允许常用端口流量: 停用
绕过中国大陆IP: 停用
DNS远程解析: 停用
路由本机代理: 启用

#启动异常时建议关闭此项后重试
混合节点: 停用
保留配置: 停用

#启动异常时建议关闭此项后重试
第三方规则: 停用

#===================== 配置文件 =====================#

mixed-port: 7893
allow-lan: true
bind-address: "*"
log-level: info
external-controller: 0.0.0.0:9090
subscribe-url:。。。
proxy-groups:
- name: Proxy
  type: select
  icon: https://raw.githubusercontent.com/Koolson/Qure/master/IconSet/Color/Proxy.png
  proxies:
  - 日本 JP
  - 新加坡 SG
  - 香港 HK
  - 美国 US
  - 全部 All
  - DIRECT
- name: 日本 JP
  type: select
  icon: https://raw.githubusercontent.com/Koolson/Qure/master/IconSet/Color/Japan.png
  use:
  - JP
- name: 新加坡 SG
  type: select
  icon: https://raw.githubusercontent.com/Koolson/Qure/master/IconSet/Color/Singapore.png
  use:
  - SG
- name: 香港 HK
  type: select
  icon: https://raw.githubusercontent.com/Koolson/Qure/master/IconSet/Color/Hong_Kong.png
  use:
  - HK
- name: 美国 US
  type: select
  icon: https://raw.githubusercontent.com/Koolson/Qure/master/IconSet/Color/United_States.png
  use:
  - US
- name: 全部 All
  type: select
  icon: https://raw.githubusercontent.com/Koolson/Qure/master/IconSet/Color/United_States.png
  use:
  - All
- name: Apple
  type: select
  icon: https://raw.githubusercontent.com/Koolson/Qure/master/IconSet/Color/Apple.png
  proxies:
  - DIRECT
  - Proxy
  - 日本 JP
  - 新加坡 SG
  - 香港 HK
  - 美国 US
- name: Google
  type: select
  icon: https://raw.githubusercontent.com/Koolson/Qure/master/IconSet/Color/Google_Search.png
  proxies:
  - Proxy
  - 日本 JP
  - 新加坡 SG
  - 香港 HK
  - 美国 US
  - DIRECT
- name: YouTube
  type: select
  icon: https://raw.githubusercontent.com/Koolson/Qure/master/IconSet/Color/YouTube.png
  proxies:
  - Proxy
  - 日本 JP
  - 新加坡 SG
  - 香港 HK
  - 美国 US
  - DIRECT
- name: Microsoft
  type: select
  icon: https://raw.githubusercontent.com/Koolson/Qure/master/IconSet/Color/Microsoft.png
  proxies:
  - DIRECT
  - Proxy
  - 日本 JP
  - 新加坡 SG
  - 香港 HK
  - 美国 US
- name: AdBlock
  type: select
  icon: https://raw.githubusercontent.com/Koolson/Qure/master/IconSet/Color/Advertising.png
  proxies:
  - REJECT
  - Proxy
  - DIRECT
rule-providers:
  adblock-domain:
    type: http
    behavior: domain
    url: https://ghproxy.com/https://raw.githubusercontent.com/Loyalsoldier/clash-rules/release/reject.txt
    path: "./rule_provider/adblock-domain.yaml"
    interval: 86400
  Apple:
    type: http
    behavior: classical
    url: https://ghproxy.com/https://raw.githubusercontent.com/blackmatrix7/ios_rule_script/master/rule/Clash/Apple/Apple.yaml
    path: "./rule_provider/Apple.yaml"
    interval: 86400
  Google:
    type: http
    behavior: classical
    url: https://ghproxy.com/https://raw.githubusercontent.com/blackmatrix7/ios_rule_script/master/rule/Clash/Google/Google.yaml
    path: "./rule_provider/Google.yaml"
    interval: 86400
  YouTube:
    type: http
    behavior: classical
    url: https://ghproxy.com/https://raw.githubusercontent.com/blackmatrix7/ios_rule_script/master/rule/Clash/YouTube/YouTube.yaml
    path: "./rule_provider/Google.yaml"
    interval: 86400
  Microsoft:
    type: http
    behavior: classical
    url: https://ghproxy.com/https://raw.githubusercontent.com/blackmatrix7/ios_rule_script/master/rule/Clash/Microsoft/Microsoft.yaml
    path: "./rule_provider/Microsoft.yaml"
    interval: 86400
  global:
    type: http
    behavior: domain
    url: https://ghproxy.com/https://raw.githubusercontent.com/Loyalsoldier/clash-rules/release/proxy.txt
    path: "./rule_provider/global.yaml"
    interval: 86400
  lan:
    type: http
    behavior: classical
    url: https://ghproxy.com/https://raw.githubusercontent.com/blackmatrix7/ios_rule_script/master/rule/Clash/Lan/Lan.yaml
    path: "./rule_provider/lan.yaml"
    interval: 86400
rules:
- DST-PORT,7895,REJECT
- DST-PORT,7892,REJECT
- IP-CIDR,198.18.0.1/16,REJECT,no-resolve
- RULE-SET,adblock-domain,AdBlock
- RULE-SET,Apple,Apple
- RULE-SET,Google,Google
- RULE-SET,YouTube,YouTube
- RULE-SET,Microsoft,Microsoft
- RULE-SET,global,Proxy
- RULE-SET,lan,DIRECT
- GEOIP,CN,DIRECT
- MATCH,Proxy
dns:
  enable: true
  ipv6: false
  listen: 0.0.0.0:7874
  default-nameserver:
  - 119.29.29.29
  - 223.5.5.5
  - 114.114.114.114
  - 192.168.0.1
  - https://1.1.1.1/dns-query
  - tls://1.1.1.1:853
  - tls://8.8.8.8:853
  enhanced-mode: fake-ip
  fake-ip-range: 198.18.0.1/16
  fake-ip-filter:
  - "*.lan"
  - "*.localdomain"
  - "*.example"
  - "*.invalid"
  - "*.localhost"
  - "*.test"
  - "*.local"
  - "*.home.arpa"
  - time.*.com
  - time.*.gov
  - time.*.edu.cn
  - time.*.apple.com
  - time1.*.com
  - time2.*.com
  - time3.*.com
  - time4.*.com
  - time5.*.com
  - time6.*.com
  - time7.*.com
  - ntp.*.com
  - ntp1.*.com
  - ntp2.*.com
  - ntp3.*.com
  - ntp4.*.com
  - ntp5.*.com
  - ntp6.*.com
  - ntp7.*.com
  - "*.time.edu.cn"
  - "*.ntp.org.cn"
  - "+.pool.ntp.org"
  - time1.cloud.tencent.com
  - music.163.com
  - "*.music.163.com"
  - "*.126.net"
  - musicapi.taihe.com
  - music.taihe.com
  - songsearch.kugou.com
  - trackercdn.kugou.com
  - "*.kuwo.cn"
  - api-jooxtt.sanook.com
  - api.joox.com
  - joox.com
  - y.qq.com
  - "*.y.qq.com"
  - streamoc.music.tc.qq.com
  - mobileoc.music.tc.qq.com
  - isure.stream.qqmusic.qq.com
  - dl.stream.qqmusic.qq.com
  - aqqmusic.tc.qq.com
  - amobile.music.tc.qq.com
  - "*.xiami.com"
  - "*.music.migu.cn"
  - music.migu.cn
  - "*.msftconnecttest.com"
  - "*.msftncsi.com"
  - msftconnecttest.com
  - msftncsi.com
  - localhost.ptlogin2.qq.com
  - localhost.sec.qq.com
  - proxy.golang.org
  - stun.*.*
  - stun.*.*.*
  - "+.stun.*.*"
  - "+.stun.*.*.*"
  - "+.stun.*.*.*.*"
  - heartbeat.belkin.com
  - "*.linksys.com"
  - "*.linksyssmartwifi.com"
  - "*.router.asus.com"
  - mesu.apple.com
  - swscan.apple.com
  - swquery.apple.com
  - swdownload.apple.com
  - swcdn.apple.com
  - swdist.apple.com
  - lens.l.google.com
  - stun.l.google.com
  - "+.nflxvideo.net"
  - "*.square-enix.com"
  - "*.finalfantasyxiv.com"
  - "*.ffxiv.com"
  - "*.mcdn.bilivideo.cn"
  - time-ios.apple.com
  - "+.msftconnecttest.com"
  - "+.msftncsi.com"
  - "+.srv.nintendo.net"
  - "*.n.n.srv.nintendo.net"
  - "+.stun.playstation.net"
  - xbox.*.*.microsoft.com
  - "*.*.xboxlive.com"
  - xbox.*.microsoft.com
  - xnotify.xboxlive.com
  - "+.battlenet.com.cn"
  - "+.wotgame.cn"
  - "+.wggames.cn"
  - "+.wowsgame.cn"
  - "+.wargaming.net"
  - "+.stun.*.*.*.*.*"
  - "*.ff14.sdo.com"
  - ff.dorado.sdo.com
  - "+.media.dssott.com"
  - shark007.net
  nameserver:
  - 192.168.0.1
  - 114.114.114.114
  - 119.29.29.29
  - 223.5.5.5
  - https://doh.pub/dns-query
  - https://dns.alidns.com/dns-query
  fallback:
  - https://dns.cloudflare.com/dns-query
  - tls://dns.google:853
  - https://1.1.1.1/dns-query
  - tls://1.1.1.1:853
  - tls://8.8.8.8:853
  - https://public.dns.iij.jp/dns-query
  - https://jp.tiar.app/dns-query
  - https://jp.tiarap.org/dns-query
  - tls://dot.tiar.app
redir-port: 7892
tproxy-port: 7895
port: 7890
socks-port: 7891
mode: rule
external-ui: "/usr/share/openclash/ui"
ipv6: false
geodata-mode: false
geodata-loader: memconservative
tcp-concurrent: true
sniffer:
  enable: true
  sniffing:
  - tls
  - http
  force-domain:
  - "+.netflix.com"
  - "+.nflxvideo.net"
  - "+.amazonaws.com"
  - "+.media.dssott.com"
  skip-domain:
  - "+.apple.com"
  - Mijia Cloud
  - "+.jd.com"
  port-whitelist:
  - 443
  - 80
profile:
  store-selected: true
  store-fake-ip: true
authentication:
- Clash:X4HjmZA3

#===================== 防火墙设置 =====================#

#IPv4 NAT chain

# Generated by iptables-save v1.8.7 on Mon Aug  8 08:21:04 2022
*nat
:PREROUTING ACCEPT [976656:334457885]
:INPUT ACCEPT [195818:13608250]
:OUTPUT ACCEPT [777561:54535531]
:POSTROUTING ACCEPT [929473:65956038]
:openclash - [0:0]
:openclash_output - [0:0]
:openclash_post - [0:0]
-A PREROUTING -d 8.8.4.4/32 -p tcp -m comment --comment "OpenClash Google DNS Hijack" -m tcp --dport 53 -j REDIRECT --to-ports 7892
-A PREROUTING -d 8.8.8.8/32 -p tcp -m comment --comment "OpenClash Google DNS Hijack" -m tcp --dport 53 -j REDIRECT --to-ports 7892
-A PREROUTING -p tcp -m tcp --dport 53 -m comment --comment "OpenClash DNS Hijack" -j REDIRECT --to-ports 53
-A PREROUTING -p udp -m udp --dport 53 -m comment --comment "OpenClash DNS Hijack" -j REDIRECT --to-ports 53
-A PREROUTING -d 192.168.0.2/32 -p udp -m udp --dport 53 -j REDIRECT --to-ports 1745
-A PREROUTING -p tcp -j openclash
-A OUTPUT -j openclash_output
-A POSTROUTING -j openclash_post
-A openclash -m set --match-set localnetwork dst -j RETURN
-A openclash -p tcp -j REDIRECT --to-ports 7892
-A openclash_output -m set --match-set localnetwork dst -j RETURN
-A openclash_output -d 198.18.0.0/16 -p tcp -m owner ! --uid-owner 65534 -j REDIRECT --to-ports 7892
-A openclash_output -p tcp -m owner ! --uid-owner 65534 -j REDIRECT --to-ports 7892
-A openclash_post -m mark --mark 0x162 -m comment --comment "OpenClash Bypass Gateway Compatible" -j ACCEPT
-A openclash_post -m comment --comment "OpenClash Bypass Gateway Compatible" -m set --match-set localnetwork dst -j RETURN
-A openclash_post -m addrtype ! --src-type LOCAL -m owner ! --uid-owner 65534 -m comment --comment "OpenClash Bypass Gateway Compatible" -j MASQUERADE
COMMIT
# Completed on Mon Aug  8 08:21:04 2022

#IPv4 Mangle chain

# Generated by iptables-save v1.8.7 on Mon Aug  8 08:21:04 2022
*mangle
:PREROUTING ACCEPT [37045622:80466371987]
:INPUT ACCEPT [13324787:25645164887]
:FORWARD ACCEPT [24883268:59073502184]
:OUTPUT ACCEPT [13059915:25628115286]
:POSTROUTING ACCEPT [37858870:84689358661]
:RRDIPT_FORWARD - [0:0]
:RRDIPT_INPUT - [0:0]
:RRDIPT_OUTPUT - [0:0]
:openclash - [0:0]
-A PREROUTING -p udp -j openclash
-A INPUT -j RRDIPT_INPUT
-A FORWARD -j RRDIPT_FORWARD
-A OUTPUT -j RRDIPT_OUTPUT
-A RRDIPT_INPUT -i eth0 -j RETURN
-A RRDIPT_INPUT -i br-lan -j RETURN
-A RRDIPT_OUTPUT -o eth0 -j RETURN
-A RRDIPT_OUTPUT -o br-lan -j RETURN
-A openclash -p udp -m udp --sport 500 -j RETURN
-A openclash -p udp -m udp --sport 68 -j RETURN
-A openclash -m set --match-set localnetwork dst -j RETURN
-A openclash -p udp -m udp --dport 53 -j RETURN
-A openclash -p udp -j TPROXY --on-port 7895 --on-ip 0.0.0.0 --tproxy-mark 0x162/0xffffffff
COMMIT
# Completed on Mon Aug  8 08:21:04 2022

#IPv4 Filter chain

# Generated by iptables-save v1.8.7 on Mon Aug  8 08:21:04 2022
*filter
:INPUT ACCEPT [0:0]
:FORWARD ACCEPT [0:0]
:OUTPUT ACCEPT [0:0]
-A INPUT -p udp -m udp --dport 443 -m comment --comment "OpenClash QUIC REJECT" -m set ! --match-set china_ip_route dst -j REJECT --reject-with icmp-port-unreachable
COMMIT
# Completed on Mon Aug  8 08:21:04 2022

#IPv6 NAT chain

#IPv6 Mangle chain

#IPv6 Filter chain

#===================== IPSET状态 =====================#

Name: china_ip_route
Name: china_ip_route_pass
Name: shuntlist
Name: gfwlist
Name: chnroute
Name: blacklist
Name: localnetwork
Name: shuntlist6
Name: gfwlist6
Name: chnroute6
Name: blacklist6

#===================== 路由表状态 =====================#

#route -n
Kernel IP routing table
Destination     Gateway         Genmask         Flags Metric Ref    Use Iface
0.0.0.0         192.168.0.1     0.0.0.0         UG    0      0        0 br-lan
192.168.0.0     0.0.0.0         255.255.255.0   U     0      0        0 br-lan
#ip route list
default via 192.168.0.1 dev br-lan proto static 
192.168.0.0/24 dev br-lan proto kernel scope link src 192.168.0.2 
#ip rule show
0:  from all lookup local
32765:  from all fwmark 0x162 lookup 354
32766:  from all lookup main
32767:  from all lookup default

#===================== 端口占用状态 =====================#

tcp        0      0 :::7890                 :::*                    LISTEN      17653/clash
tcp        0      0 :::7891                 :::*                    LISTEN      17653/clash
tcp        0      0 :::7892                 :::*                    LISTEN      17653/clash
tcp        0      0 :::7893                 :::*                    LISTEN      17653/clash
tcp        0      0 :::7895                 :::*                    LISTEN      17653/clash
tcp        0      0 :::9090                 :::*                    LISTEN      17653/clash
udp        0      0 0.0.0.0:45516           0.0.0.0:*                           17653/clash
udp        0      0 0.0.0.0:60959           0.0.0.0:*                           17653/clash
udp        0      0 0.0.0.0:57539           0.0.0.0:*                           17653/clash
udp        0      0 0.0.0.0:49358           0.0.0.0:*                           17653/clash
udp        0      0 :::7874                 :::*                                17653/clash
udp        0      0 :::7891                 :::*                                17653/clash
udp        0      0 :::7892                 :::*                                17653/clash
udp        0      0 :::7893                 :::*                                17653/clash
udp        0      0 :::7895                 :::*                                17653/clash

#===================== 测试本机DNS查询 =====================#

Server:     127.0.0.1
Address:    127.0.0.1:53

Name:   www.baidu.com
Address: 198.18.0.13

#===================== resolv.conf.d =====================#

# Interface lan
nameserver 192.168.0.1

#===================== 测试本机网络连接 =====================#

HTTP/1.1 200 OK
Accept-Ranges: bytes
Cache-Control: private, no-cache, no-store, proxy-revalidate, no-transform
Connection: keep-alive
Content-Length: 277
Content-Type: text/html
Date: Mon, 08 Aug 2022 00:21:10 GMT
Etag: "575e1f60-115"
Last-Modified: Mon, 13 Jun 2016 02:50:08 GMT
Pragma: no-cache
Server: bfe/1.0.8.18

#===================== 测试本机网络下载 =====================#

HTTP/2 200 
cache-control: max-age=300
content-security-policy: default-src 'none'; style-src 'unsafe-inline'; sandbox
content-type: text/plain; charset=utf-8
etag: "8c9c2724dbecd721d24a35117a8c4e28d61e5a152a6107e6a8242986b9ec1eba"
strict-transport-security: max-age=31536000
x-content-type-options: nosniff
x-frame-options: deny
x-xss-protection: 1; mode=block
x-github-request-id: 132C:1B1F:9C5314:CF8DF5:62EFC109
accept-ranges: bytes
date: Mon, 08 Aug 2022 00:21:10 GMT
via: 1.1 varnish
x-served-by: cache-hnd18720-HND
x-cache: HIT
x-cache-hits: 1
x-timer: S1659918071.539222,VS0,VE1
vary: Authorization,Accept-Encoding,Origin
access-control-allow-origin: *
x-fastly-request-id: 0a4ae1326dbf88afc2b4f22603e31f1af345d2ee
expires: Mon, 08 Aug 2022 00:26:10 GMT
source-age: 165
content-length: 80

#===================== 最近运行日志 =====================#

time="2022-08-08T08:20:42+08:00" level=info msg="[TCP] [Clash.Meta] --> ghproxy.com:443 match Match using Proxy[【直连】东京 - 原生解锁 - 1]"
time="2022-08-08T08:20:42+08:00" level=info msg="[TCP] [Clash.Meta] --> ghproxy.com:443 match Match using Proxy[【直连】东京 - 原生解锁 - 1]"
time="2022-08-08T08:20:42+08:00" level=info msg="[TCP] [Clash.Meta] --> ghproxy.com:443 match Match using Proxy[【直连】东京 - 原生解锁 - 1]"
time="2022-08-08T08:20:42+08:00" level=info msg="[TCP] [Clash.Meta] --> ghproxy.com:443 match Match using Proxy[【直连】东京 - 原生解锁 - 1]"
time="2022-08-08T08:20:42+08:00" level=info msg="[TCP] [Clash.Meta] --> ghproxy.com:443 match Match using Proxy[【直连】东京 - 原生解锁 - 1]"
time="2022-08-08T08:20:45+08:00" level=info msg="Use tcp concurrent"
time="2022-08-08T08:20:45+08:00" level=info msg="HTTP proxy listening at: [::]:7890"
time="2022-08-08T08:20:45+08:00" level=info msg="SOCKS proxy listening at: [::]:7891"
time="2022-08-08T08:20:45+08:00" level=info msg="Redirect proxy listening at: [::]:7892"
time="2022-08-08T08:20:45+08:00" level=info msg="TProxy server listening at: [::]:7895"
time="2022-08-08T08:20:45+08:00" level=info msg="Mixed(http+socks) proxy listening at: [::]:7893"
time="2022-08-08T08:20:45+08:00" level=info msg="[UDP] 192.168.0.2:60785 --> 180.97.34.28:8829 match GeoIP(CN) using DIRECT"
time="2022-08-08T08:20:46+08:00" level=info msg="[TCP] 192.168.0.100:57410 --> www.google.com:443 match RuleSet(Google) using Google[【直连】东京 - 原生解锁 - 1]"
time="2022-08-08T08:20:46+08:00" level=info msg="[TCP] 192.168.0.107:47196 --> 123.151.54.38:8080 match GeoIP(CN) using DIRECT"
time="2022-08-08T08:20:48+08:00" level=info msg="[TCP] 192.168.0.100:57413 --> mask-h2.icloud.com:443 match RuleSet(Apple) using Apple[DIRECT]"
time="2022-08-08T08:20:48+08:00" level=info msg="[UDP] 192.168.0.2:54321 --> 45.124.124.122:8053 match GeoIP(CN) using DIRECT"
time="2022-08-08T08:20:48+08:00" level=info msg="[TCP] 192.168.0.100:57416 --> mask-h2.icloud.com:443 match RuleSet(Apple) using Apple[DIRECT]"
time="2022-08-08T08:20:49+08:00" level=info msg="[TCP] 192.168.0.100:57418 --> mask-api.icloud.com:443 match RuleSet(Apple) using Apple[DIRECT]"
time="2022-08-08T08:20:49+08:00" level=info msg="[TCP] 192.168.0.100:57419 --> rr1---sn-3pm7sne7.googlevideo.com:443 match RuleSet(Google) using Google[【直连】东京 - 原生解锁 - 1]"
time="2022-08-08T08:20:49+08:00" level=info msg="[TCP] 192.168.0.100:58224 --> 17.56.138.30:443 match RuleSet(Apple) using Apple[DIRECT]"
time="2022-08-08T08:20:50+08:00" level=info msg="[TCP] 192.168.0.100:57421 --> aa.google.com:443 match RuleSet(Google) using Google[【直连】东京 - 原生解锁 - 1]"
time="2022-08-08T08:20:51+08:00" level=info msg="[TCP] 192.168.0.100:58225 --> 91.108.56.171:443 match Match using Proxy[【直连】东京 - 原生解锁 - 1]"
time="2022-08-08T08:20:52+08:00" level=info msg="[TCP] 192.168.0.102:62658 --> 124.237.224.9:443 match GeoIP(CN) using DIRECT"
time="2022-08-08T08:20:52+08:00" level=info msg="[TCP] 192.168.0.102:62655 --> 124.237.224.8:443 match GeoIP(CN) using DIRECT"
time="2022-08-08T08:20:53+08:00" level=info msg="[TCP] 192.168.0.118:40708 --> dig.bdurl.net:443 match RuleSet(adblock-domain) using AdBlock[REJECT]"
time="2022-08-08T08:20:53+08:00" level=info msg="[TCP] 192.168.0.118:40710 --> dig.bdurl.net:443 match RuleSet(adblock-domain) using AdBlock[REJECT]"
time="2022-08-08T08:20:54+08:00" level=info msg="[UDP] 192.168.0.2:42592 --> 150.138.174.157:443 match GeoIP(CN) using DIRECT"
time="2022-08-08T08:20:54+08:00" level=info msg="[TCP] 192.168.0.100:57435 --> amp-api.music.apple.com:443 match RuleSet(Apple) using Apple[DIRECT]"
time="2022-08-08T08:20:55+08:00" level=info msg="[TCP] 192.168.0.118:43426 --> p1.toutiaoimg.com:443 match GeoIP(CN) using DIRECT"
time="2022-08-08T08:20:55+08:00" level=info msg="[TCP] 192.168.0.100:57438 --> mask-h2.icloud.com:443 match RuleSet(Apple) using Apple[DIRECT]"
time="2022-08-08T08:20:58+08:00" level=info msg="[TCP] 192.168.0.118:37940 --> sf6-cdn-tos.toutiaostatic.com:443 match GeoIP(CN) using DIRECT"
time="2022-08-08T08:20:58+08:00" level=info msg="[TCP] 192.168.0.118:38536 --> sf3-cdn-tos.toutiaostatic.com:443 match GeoIP(CN) using DIRECT"
time="2022-08-08T08:20:59+08:00" level=info msg="[UDP] 192.168.0.2:46587 --> 45.124.124.51:8053 match GeoIP(CN) using DIRECT"
time="2022-08-08T08:21:00+08:00" level=info msg="[TCP] 192.168.0.100:57448 --> 150.138.167.141:443 match GeoIP(CN) using DIRECT"
time="2022-08-08T08:21:00+08:00" level=info msg="[TCP] 192.168.0.107:48804 --> aeventlog.beacon.qq.com:8081 match RuleSet(adblock-domain) using AdBlock[REJECT]"
time="2022-08-08T08:21:00+08:00" level=info msg="[TCP] 192.168.0.100:58226 --> 17.56.138.30:443 match RuleSet(Apple) using Apple[DIRECT]"
time="2022-08-08T08:21:01+08:00" level=info msg="[TCP] 192.168.0.100:57449 --> 150.138.167.141:443 match GeoIP(CN) using DIRECT"
time="2022-08-08T08:21:01+08:00" level=info msg="[TCP] 192.168.0.100:57450 --> 150.138.167.141:443 match GeoIP(CN) using DIRECT"
time="2022-08-08T08:21:01+08:00" level=info msg="[TCP] 192.168.0.100:57453 --> pancake.apple.com:443 match RuleSet(Apple) using Apple[DIRECT]"
time="2022-08-08T08:21:01+08:00" level=info msg="[TCP] 192.168.0.100:57454 --> pancake.apple.com:443 match RuleSet(Apple) using Apple[DIRECT]"
time="2022-08-08T08:21:01+08:00" level=info msg="[TCP] 192.168.0.100:57455 --> 150.138.167.141:443 match GeoIP(CN) using DIRECT"
time="2022-08-08T08:21:01+08:00" level=info msg="[TCP] 192.168.0.100:57456 --> pancake.apple.com:443 match RuleSet(Apple) using Apple[DIRECT]"
time="2022-08-08T08:21:02+08:00" level=info msg="[TCP] 192.168.0.100:57460 --> gateway.icloud.com.cn:443 match RuleSet(Apple) using Apple[DIRECT]"
time="2022-08-08T08:21:05+08:00" level=info msg="[TCP] 192.168.0.101:49700 --> gateway.icloud.com.cn:443 match RuleSet(Apple) using Apple[DIRECT]"
time="2022-08-08T08:21:05+08:00" level=info msg="[TCP] 192.168.0.101:49702 --> gateway.icloud.com:443 match RuleSet(Apple) using Apple[DIRECT]"
time="2022-08-08T08:21:06+08:00" level=info msg="[TCP] 192.168.0.102:62661 --> 124.237.224.8:443 match GeoIP(CN) using DIRECT"
time="2022-08-08T08:21:07+08:00" level=info msg="[TCP] 192.168.0.100:57465 --> pancake.apple.com:443 match RuleSet(Apple) using Apple[DIRECT]"
time="2022-08-08T08:21:07+08:00" level=info msg="[TCP] 192.168.0.100:57466 --> pancake.apple.com:443 match RuleSet(Apple) using Apple[DIRECT]"
time="2022-08-08T08:21:10+08:00" level=info msg="[TCP] 192.168.0.2:58748 --> www.baidu.com:80 match GeoIP(CN) using DIRECT"
time="2022-08-08T08:21:10+08:00" level=info msg="[TCP] 192.168.0.2:39332 --> raw.githubusercontent.com:443 match RuleSet(global) using Proxy[【直连】东京 - 原生解锁 - 1]"

#===================== 活动连接信息 =====================#

1. SourceIP:【192.168.0.100】 - Host:【www.google.com】 - DestinationIP:【】 - Network:【tcp】 - RulePayload:【Google】 - Lastchain:【【直连】东京 - 原生解锁 - 1】
2. SourceIP:【192.168.0.100】 - Host:【rr1---sn-3pm7sne7.googlevideo.com】 - DestinationIP:【157.240.17.36】 - Network:【tcp】 - RulePayload:【Google】 - Lastchain:【【直连】东京 - 原生解锁 - 1】
3. SourceIP:【】 - Host:【api.v1.mk】 - DestinationIP:【172.67.180.200】 - Network:【tcp】 - RulePayload:【】 - Lastchain:【COMPATIBLE】
4. SourceIP:【192.168.0.100】 - Host:【Empty】 - DestinationIP:【17.56.138.30】 - Network:【tcp】 - RulePayload:【Apple】 - Lastchain:【DIRECT】
5. SourceIP:【192.168.0.118】 - Host:【sf6-cdn-tos.toutiaostatic.com】 - DestinationIP:【36.99.119.110】 - Network:【tcp】 - RulePayload:【CN】 - Lastchain:【DIRECT】
6. SourceIP:【192.168.0.100】 - Host:【Empty】 - DestinationIP:【150.138.167.141】 - Network:【tcp】 - RulePayload:【CN】 - Lastchain:【DIRECT】
7. SourceIP:【】 - Host:【ghproxy.com】 - DestinationIP:【144.24.81.189】 - Network:【tcp】 - RulePayload:【】 - Lastchain:【【直连】东京 - 原生解锁 - 1】
8. SourceIP:【192.168.0.100】 - Host:【mask-api.icloud.com】 - DestinationIP:【】 - Network:【tcp】 - RulePayload:【Apple】 - Lastchain:【DIRECT】
9. SourceIP:【192.168.0.2】 - Host:【Empty】 - DestinationIP:【45.124.124.51】 - Network:【udp】 - RulePayload:【CN】 - Lastchain:【DIRECT】
10. SourceIP:【】 - Host:【api.v1.mk】 - DestinationIP:【172.67.180.200】 - Network:【tcp】 - RulePayload:【】 - Lastchain:【COMPATIBLE】
11. SourceIP:【192.168.0.100】 - Host:【aa.google.com】 - DestinationIP:【】 - Network:【tcp】 - RulePayload:【Google】 - Lastchain:【【直连】东京 - 原生解锁 - 1】
12. SourceIP:【192.168.0.100】 - Host:【Empty】 - DestinationIP:【91.108.56.171】 - Network:【tcp】 - RulePayload:【】 - Lastchain:【【直连】东京 - 原生解锁 - 1】
13. SourceIP:【192.168.0.118】 - Host:【sf3-cdn-tos.toutiaostatic.com】 - DestinationIP:【182.40.19.118】 - Network:【tcp】 - RulePayload:【CN】 - Lastchain:【DIRECT】
14. SourceIP:【192.168.0.100】 - Host:【mask-h2.icloud.com】 - DestinationIP:【17.248.152.142】 - Network:【tcp】 - RulePayload:【Apple】 - Lastchain:【DIRECT】
15. SourceIP:【】 - Host:【ghproxy.com】 - DestinationIP:【144.24.81.189】 - Network:【tcp】 - RulePayload:【】 - Lastchain:【【直连】东京 - 原生解锁 - 1】
16. SourceIP:【192.168.0.102】 - Host:【Empty】 - DestinationIP:【124.237.224.8】 - Network:【tcp】 - RulePayload:【CN】 - Lastchain:【DIRECT】
17. SourceIP:【】 - Host:【ghproxy.com】 - DestinationIP:【144.24.81.189】 - Network:【tcp】 - RulePayload:【】 - Lastchain:【【直连】东京 - 原生解锁 - 1】
18. SourceIP:【】 - Host:【ghproxy.com】 - DestinationIP:【144.24.81.189】 - Network:【tcp】 - RulePayload:【】 - Lastchain:【【直连】东京 - 原生解锁 - 1】
19. SourceIP:【】 - Host:【ghproxy.com】 - DestinationIP:【144.24.81.189】 - Network:【tcp】 - RulePayload:【】 - Lastchain:【【直连】东京 - 原生解锁 - 1】
20. SourceIP:【】 - Host:【ghproxy.com】 - DestinationIP:【144.24.81.189】 - Network:【tcp】 - RulePayload:【】 - Lastchain:【【直连】东京 - 原生解锁 - 1】
21. SourceIP:【192.168.0.100】 - Host:【mask-h2.icloud.com】 - DestinationIP:【】 - Network:【tcp】 - RulePayload:【Apple】 - Lastchain:【DIRECT】
22. SourceIP:【192.168.0.2】 - Host:【Empty】 - DestinationIP:【45.124.124.122】 - Network:【udp】 - RulePayload:【CN】 - Lastchain:【DIRECT】
23. SourceIP:【192.168.0.118】 - Host:【p1.toutiaoimg.com】 - DestinationIP:【150.138.101.76】 - Network:【tcp】 - RulePayload:【CN】 - Lastchain:【DIRECT】
24. SourceIP:【192.168.0.102】 - Host:【Empty】 - DestinationIP:【124.237.224.9】 - Network:【tcp】 - RulePayload:【CN】 - Lastchain:【DIRECT】
25. SourceIP:【】 - Host:【api.v1.mk】 - DestinationIP:【172.67.180.200】 - Network:【tcp】 - RulePayload:【】 - Lastchain:【COMPATIBLE】
26. SourceIP:【192.168.0.100】 - Host:【Empty】 - DestinationIP:【150.138.167.141】 - Network:【tcp】 - RulePayload:【CN】 - Lastchain:【DIRECT】
27. SourceIP:【192.168.0.100】 - Host:【amp-api.music.apple.com】 - DestinationIP:【】 - Network:【tcp】 - RulePayload:【Apple】 - Lastchain:【DIRECT】
28. SourceIP:【192.168.0.100】 - Host:【Empty】 - DestinationIP:【150.138.167.141】 - Network:【tcp】 - RulePayload:【CN】 - Lastchain:【DIRECT】
29. SourceIP:【192.168.0.2】 - Host:【Empty】 - DestinationIP:【150.138.174.157】 - Network:【udp】 - RulePayload:【CN】 - Lastchain:【DIRECT】
30. SourceIP:【192.168.0.2】 - Host:【Empty】 - DestinationIP:【180.97.34.28】 - Network:【udp】 - RulePayload:【CN】 - Lastchain:【DIRECT】
31. SourceIP:【】 - Host:【api.v1.mk】 - DestinationIP:【172.67.180.200】 - Network:【tcp】 - RulePayload:【】 - Lastchain:【COMPATIBLE】
32. SourceIP:【192.168.0.100】 - Host:【mask-h2.icloud.com】 - DestinationIP:【】 - Network:【tcp】 - RulePayload:【Apple】 - Lastchain:【DIRECT】
33. SourceIP:【】 - Host:【ghproxy.com】 - DestinationIP:【144.24.81.189】 - Network:【tcp】 - RulePayload:【】 - Lastchain:【【直连】东京 - 原生解锁 - 1】
34. SourceIP:【192.168.0.100】 - Host:【Empty】 - DestinationIP:【150.138.167.141】 - Network:【tcp】 - RulePayload:【CN】 - Lastchain:【DIRECT】
35. SourceIP:【】 - Host:【api.v1.mk】 - DestinationIP:【104.21.18.71】 - Network:【tcp】 - RulePayload:【】 - Lastchain:【COMPATIBLE】
36. SourceIP:【192.168.0.107】 - Host:【Empty】 - DestinationIP:【123.151.54.38】 - Network:【tcp】 - RulePayload:【CN】 - Lastchain:【DIRECT】

OpenClash Config

No response

Expected Behavior

待机耗电恢复正常水平

Screenshots

以下测试在一台 iPhone 7 上进行：全程除查看电量外不操作手机，因此 App 电池用量处仅显示“设置”，用量几分钟。

可见使用 PassWall 时待机电量消耗正常；在其他设备操作关闭 PassWall 并开启 OpenClash，会立即影响到手机耗电。

一直开启 OpenClash，电量消耗严重。

IMG_5AEB50ACD145-1

关闭 OpenClash，手机本机运行 Stash，电量消耗正常。

imhanjie commented 2 years ago

我和你一样，一直有这个情况，我也是 R2S，做的主路由，固件基本都试过，包括原版的 OpenWrt，经过我多次待机测试：

测试设备：iPhone 13 Pro、iPhone XR、iPad Air 4

OpenClash：Redir-host 模式 [待机耗电异常]、Fake-ip [待机耗电异常]
ShellClash：Redir-host 模式 [待机耗电正常]、Fake-ip [待机耗电异常]

所以目前只能用的 ShellClash：Redir-host 模式才能正常

eightsheep67 commented 2 years ago

这会是什么问题？神奇，cy一下

leeharuhiofcn commented 2 years ago

很好奇，关注一下。

Skyxim commented 2 years ago

删除 Ad 规则

tangfenga commented 2 years ago

不要发布无意义的回复，大家有同样情况的可以将自己的网络环境阐述一下，方便找出问题

Franky18 commented 2 years ago

X86也遇到了同样的问题，我今天测试了删除苹果相关规则（之前用的ACL4的苹果规则，规则比较简单没有blackmatrix7全面，且为直连），让苹果走Final（final是走代理），耗电情况应该是正常了。模式为：redir-host，有时间再测试一下fake-ip。

Franky18 commented 2 years ago

我没有使用过passwall，想问一下你测试的passwall耗电情况细节问题。passwall设置的是什么分流规则，gfw列表还是绕过中国大陆IP？passwall有无设置苹果规则？如有设置，苹果连接走直连还是代理？

QuincySx commented 2 years ago

X86也遇到了同样的问题，我今天测试了删除苹果相关规则（之前用的ACL4的苹果规则，规则比较简单没有blackmatrix7全面，且为直连），让苹果走Final（final是走代理），耗电情况应该是正常了。模式为：redir-host，有时间再测试一下fake-ip。

你是只把里面 Apple-proxy.list 走代理了。还是整个 Apple.list 全走代理了，

cubarco commented 2 years ago

@Franky18

... 让苹果走Final（final是走代理），耗电情况应该是正常了 ...

这两天调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的成因。

Franky18 commented 2 years ago

@Franky18

... 让苹果走Final（final是走代理），耗电情况应该是正常了 ...

这两天调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误判的情况，但依然有耗电增加的问题。

Franky18 commented 2 years ago

X86也遇到了同样的问题，我今天测试了删除苹果相关规则（之前用的ACL4的苹果规则，规则比较简单没有blackmatrix7全面，且为直连），让苹果走Final（final是走代理），耗电情况应该是正常了。模式为：redir-host，有时间再测试一下fake-ip。

你是只把里面 Apple-proxy.list 走代理了。还是整个 Apple.list 全走代理了，

直接删除苹果相关所有规则，苹果的域名链接让clash查询dns，用ip判断是走geo ip cn（直连）还是final（代理），苹果的ip链接也是如此。

LovelyToaster commented 1 year ago

可以试试让所有会保持长连接的地址绕过内核，我的小米手机也出现了待机耗电异常的情况，发现待机时持续未知原因的唤醒，再将Google FCM和小米push绕过内核后，情况立刻消失

cubarco commented 1 year ago

可以试试让所有会保持长连接的地址绕过内核，我的小米手机也出现了待机耗电异常的情况，发现待机时持续未知原因的唤醒，再将Google FCM和小米push绕过内核后，情况立刻消失

@LovelyToaster 请问mipush绕过内核走的是IP白名单吗？网上没找到mipush的ip段，可否提供下？

update: 好像不需要，直接所有china ip都绕内核就好了；只有apple和fcm的国外ip段需要单独处理

LovelyToaster commented 1 year ago

可以试试让所有会保持长连接的地址绕过内核，我的小米手机也出现了待机耗电异常的情况，发现待机时持续未知原因的唤醒，再将Google FCM和小米push绕过内核后，情况立刻消失

@LovelyToaster 请问mipush绕过内核走的是IP白名单吗？网上没找到mipush的ip段，可否提供下？

update: 好像不需要，直接所有china ip都绕内核就好了；只有apple和fcm的国外ip段需要单独处理

确实，我是直接china ip都绕过内核，然后fcm单独处理

LovelyToaster commented 1 year ago

可以试试让所有会保持长连接的地址绕过内核，我的小米手机也出现了待机耗电异常的情况，发现待机时持续未知原因的唤醒，再将Google FCM和小米push绕过内核后，情况立刻消失

@LovelyToaster 请问mipush绕过内核走的是IP白名单吗？网上没找到mipush的ip段，可否提供下？

update: 好像不需要，直接所有china ip都绕内核就好了；只有apple和fcm的国外ip段需要单独处理

其实好像是只要走内核的连接都会造成我的手机唤醒耗电，我把mipush和FCM绕过内核让情况消失的前提是我对于手机的大部分应用回到后台后链接会被关闭，而且中国ip段绕过内核

cubarco commented 1 year ago

其实好像是只要走内核的连接都会造成我的手机唤醒耗电，我把mipush和FCM绕过内核让情况消失的前提是我对于手机的大部分应用回到后台后链接会被关闭，而且中国ip段绕过内核

刚才发现了这个issue：https://github.com/v2ray/v2ray-core/issues/2564 测试了一下，走clash内核(direct)的长连接，每15秒都有个keep-alive包从clash内核发到客户端：

17:43:56.475915 IP localhost.7890 > localhost.56426: Flags [.], ack 1, win 512, options [nop,nop,TS val 3880779461 ecr 3880764357], length 0
17:43:56.475948 IP localhost.56426 > localhost.7890: Flags [.], ack 1, win 512, options [nop,nop,TS val 3880779462 ecr 3880734189], length 0

17:44:11.579883 IP localhost.7890 > localhost.56426: Flags [.], ack 1, win 512, options [nop,nop,TS val 3880794565 ecr 3880779462], length 0
17:44:11.579915 IP localhost.56426 > localhost.7890: Flags [.], ack 1, win 512, options [nop,nop,TS val 3880794565 ecr 3880734189], length 0

结合你的现象，猜测应该是golang的这个15秒interval的问题（clash内核也是go写的）；至于是不是本issue的成因，还需要再测测。（如果是，可能也不是这个repo能解决的了）

cubarco commented 1 year ago

关联一个clash的issue：https://github.com/Dreamacro/clash/issues/996

LovelyToaster commented 1 year ago

关联一个clash的issue：https://github.com/Dreamacro/clash/issues/996

按照这个issue 我自编译了一个内核，发现唤醒确实恢复正常了，耗电情况时间太短不确定

0x1301FDF commented 1 year ago

@Franky18

... 让苹果走Final（final是走代理），耗电情况应该是正常了 ...

这两天调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的成因。

关注下，我也是Redir-host模式下把apple相关域名设置直连之后，包括32-courier.push.apple.com，apple-dns.net之类的，晚上待机耗电加快

XCJYO commented 1 year ago

更换GEOIP能否解决？另外苹果商店的软件下载明显变慢，比不用软路由慢的多

XCJYO commented 1 year ago

X86也遇到了同样的问题，我今天测试了删除苹果相关规则（之前用的ACL4的苹果规则，规则比较简单没有blackmatrix7全面，且为直连），让苹果走Final（final是走代理），耗电情况应该是正常了。模式为：redir-host，有时间再测试一下fake-ip。

我也是订阅转换用的ACL4的,然后切换mate模式在规则集与策略组管理里加上的blackmatrix7的，应该是这样操作的吧？

cubarco commented 1 year ago

我给clash加长了keep-alive心跳间隔时长（默认是15s），并经过吃灰iPad一个多月的待机验证，观测到待机耗电确实是在减少了。至少对我来说clash的续航问题应该是这个issue导致的。

我的解决方案是在Clash.Meta上简单修改了一下keep-alive的心跳间隔：https://github.com/cubarco/Clash.Meta/commit/e5a0e6c0abc755391ee25f83cd4604715b96b4d5 。有异常耗电问题的朋友可以尝试下，release里面有预编译的binary。

Franky18 commented 1 year ago

我给clash加长了keep-alive心跳间隔时长（默认是15s），并经过吃灰iPad一个多月的待机验证，观测到待机耗电确实是在减少了。至少对我来说clash的续航问题应该是这个issue导致的。

我的解决方案是在Clash.Meta上简单修改了一下keep-alive的心跳间隔：cubarco/Clash.Meta@e5a0e6c 。有异常耗电问题的朋友可以尝试下，release里面有预编译的binary。

感谢大佬！我不严谨的测试了几天，耗电情况确实有改善。赞！

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

akira304moto commented 1 year ago

up

kangbingbing commented 1 year ago

我也遇到了类似的问题，我手机使用passwall 时待机基本走横线，不掉电，或者很少的电，使用open clash 后，晚上7个小时基本掉电20%+，其他用着很舒服，这点是真难受😁

yinghuansouqi commented 1 year ago

更换GEOIP能否解决？另外苹果商店的软件下载明显变慢，比不用软路由慢的多

我也有这个问题，苹果商店时快时慢，大部分时间只能稳定在2M，偶尔满速，好像跟版本也有关系，最近的版本有这个问题，以前没有，同时三星商店没这个问题

ForestL18 commented 1 year ago

可以试试让所有会保持长连接的地址绕过内核，我的小米手机也出现了待机耗电异常的情况，发现待机时持续未知原因的唤醒，再将Google FCM和小米push绕过内核后，情况立刻消失

@LovelyToaster 请问mipush绕过内核走的是IP白名单吗？网上没找到mipush的ip段，可否提供下？ update: 好像不需要，直接所有china ip都绕内核就好了；只有apple和fcm的国外ip段需要单独处理

确实，我是直接china ip都绕过内核，然后fcm单独处理

可以问下你的fcm的IP列表从哪找的吗？

LovelyToaster commented 1 year ago

可以试试让所有会保持长连接的地址绕过内核，我的小米手机也出现了待机耗电异常的情况，发现待机时持续未知原因的唤醒，再将Google FCM和小米push绕过内核后，情况立刻消失

@LovelyToaster 请问mipush绕过内核走的是IP白名单吗？网上没找到mipush的ip段，可否提供下？ update: 好像不需要，直接所有china ip都绕内核就好了；只有apple和fcm的国外ip段需要单独处理

确实，我是直接china ip都绕过内核，然后fcm单独处理

可以问下你的fcm的IP列表从哪找的吗？

ACL4SSR的库里面，不过也可以直接屏蔽5228这个端口号

ForestL18 commented 1 year ago

如何屏蔽端口号，老哥可以大概说一下吗，谢谢

是指这个吗？

LovelyToaster commented 1 year ago

如何屏蔽端口号，老哥可以大概说一下吗，谢谢

是指这个吗？

是的绕过5228即可

Vegas7 commented 1 year ago

如何屏蔽端口号，老哥可以大概说一下吗，谢谢是指这个吗？

是的绕过5228即可

在这里添加了Apple APN的5223，应用后查看使用5223的连接还是会经过内核，不知道为何没有生效？

silverzhaojr commented 1 year ago

刚才发现了这个issue：v2ray/v2ray-core#2564 测试了一下，走clash内核(direct)的长连接，每15秒都有个keep-alive包从clash内核发到客户端： ...

结合你的现象，猜测应该是golang的这个15秒interval的问题（clash内核也是go写的）；至于是不是本issue的成因，还需要再测测。（如果是，可能也不是这个repo能解决的了）

你好，我想请问下如何重现这个 15s 间隔的 keep alive 包？

我试了好几次，发现长连接保持非活跃状态时，clash meta 内核会每隔 30s 分别向客户端和服务端发送 keep alive 包，对应于这里的代码：

https://github.com/MetaCubeX/Clash.Meta/blob/53f9e1ee7104473da2b4ff5da29965563084482d/adapter/outbound/util.go#L28

func tcpKeepAlive(c net.Conn) {
    if tcp, ok := c.(*net.TCPConn); ok {
        _ = tcp.SetKeepAlive(true)
        _ = tcp.SetKeepAlivePeriod(30 * time.Second)
    }
}

clash config 很简单，只有 mixed-port: 7890 一行，重现步骤是本地首先通过 nc 监听 45678 端口，然后再通过 clash socks5 代理连接该端口，我这边观察到的是 30s 一次的 keep alive 包，如图所示：

这些 keep alive 包会不断唤醒手机，我想这应该就是在 Apple Push/Google FCM 等长连接经过 clash 时，手机会不断耗电的原因。不管规则判定是直连还是通过远程节点连接，只要由 clash 内核发出连接皆会如此。

cubarco commented 1 year ago

你好，我想请问下如何重现这个 15s 间隔的 keep alive 包？

@silverzhaojr

hi，我看了一下你的tcpdump命令，是在尝试抓取45678，也就是clash -> remote server这一段的包。而这个issue的成因，是client -> clash这一段的长链接keepalive。所以，在你的环境里，可以尝试抓包12345端口tcp包。

不过我不确定clash的socks5会不会也有15s的keepalive包，本issue的场景是redir或者tun。如果socks5抓不到15s的keepalive，你可以尝试redir模式，然后同样是抓client -> clash这一段的包。

silverzhaojr commented 1 year ago

我又仔细研究了下，可以确定是 clash 内核会每隔 15s 发出 keep alive 包不断唤醒手机，从而导致持续耗电。重现步骤如下：

clash 配置文件很简单，只有 mixed-port: 7890 一行；
本地起个服务，监听 45678 端口，模拟 Apple Push / Google FCM 服务器；
```
$ nc -l 45678
```
本地通过 clash socks5 代理连接上述端口，模拟手机连接推送服务器，本地端口为 12345；
```
$ nc -p 12345 -X 5 -x 127.0.0.1:7890 127.0.0.1 45678
```
使用 tcpdump 监测客户端端口 12345 上的网络包，可以看到 clash 内核每隔 15s 就会发送过来一个包，这些数据包会不断唤醒手机；
```
$ sudo tcpdump -i lo -n port 12345
```
我试了下 redir 模式，也是如此(图中我是通过 iptables 把端口 1234 的数据包 REDIRECT 至 clash redir 端口 7892)。事实上，所有模式都是这样，因为只要启用了 golang 的 keep alive 机制，默认 interval 就是 15s；
```
conn.(*net.TCPConn).SetKeepAlive(true)
```
https://github.com/search?q=repo%3AMetaCubeX%2FClash.Meta%20SetKeepAlive&type=code

整个过程如图所示：

socks5 模式：

redir 模式：

silverzhaojr commented 1 year ago

参考这个 issue golang/go/issues/48622 ，具体原因应该如下：

Google FCM / Apple Push 在与手机建立长连接后，它通常会在一定时间内发送心跳包，以维持该连接不被 nat 丢弃掉，这个心跳间隔通常为 5min ~ 28min。
如果该连接通过 clash 接手发起(不管是直连，还是通过远程节点连接)，由于 go 默认启用了 keep alive，在发现该连接持续 KEEP_IDLE (15s) 没有数据活动，它会发起一个 keep alive 包给客户端(手机)：
- 如果客户端回应了，则表明该连接有效，clash 内核会在再次 KEEP_IDLE (15s) 后发出 keep alive 包探测；
- 如果客户端没有回应(离线，不再连接到 clash)，clash 内核会每间隔 KEEP_ALIVE_INTERVAL (15s) 发送一次探测包，持续发送 KEEP_COUNT (默认值为 9) 次后，如果一直没有收到回应，则认为连接无效，会从内存中清除相关的连接信息；
可见，对于正常的长连接来说，每隔 KEEP_IDLE (15s) 就会有一次探测包来唤醒手机，这种情况下耗电显然可观了。
根本原因是 go 默认将 KEEP_IDLE 和 KEEP_ALIVE_INTERVAL 设为相同，且其数值太小。

事实上 KEEP_IDLE 可以设置得比较大些，比如 10min ，而 KEEP_ALIVE_INTERVAL 可以是 15s，这样极端情况下，该无效连接最多会在内核中占据内存持续 10min + 15s * 9 = 735s，然后被移除。由于这时候客户端(手机)已经离线，所以这些探测包永远不会到达手机从而也不会再唤醒手机。
目前情况下，Go 语言无法单独设置 KEEP_IDLE 和 KEEP_ALIVE_INTERVAL，只能同时设置： https://go.dev/src/net/tcpsockopt_unix.go

若将其均设为 10min，则无效连接在内存中最多会保持 10min + 10min * 9 = 100min。由于客户端离开 clash 情况比较少见，且通常只会有一两个长连接，这样时长的内存占用应该是可以接受的。

silverzhaojr commented 1 year ago

由于目前官方 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

cubarco commented 1 year ago

由于目前官方 Clash 团队还没有关注这个 Dreamacro/clash#2867 ，所以我直接改了下代码，将 TCP keep alive interval 设为了 1800s。大家可以测试看下，看看是否解决了这个问题：

https://github.com/silverzhaojr/clash/releases/tag/v1.18.0-fix-tcp-keep-alive

@silverzhaojr 你可以在这个issue里面网上翻翻，这个方案我已经提过：https://github.com/cubarco/Clash.Meta/commit/e5a0e6c0abc755391ee25f83cd4604715b96b4d5 ，而且验证是有效的。

silverzhaojr commented 1 year ago

@silverzhaojr 你可以在这个issue里面网上翻翻，这个方案我已经提过：cubarco/Clash.Meta@e5a0e6c ，而且验证是有效的。

我就是看了你这个代码做的改动🤣。这里主要是基于 Clash 的最新版本编译了下带有修复的代码，方便其他遇到这个问题的人暂时用着。

lvii commented 1 year ago

由于目前官方 Clash 团队还没有关注这个 Dreamacro/clash#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 ，而且验证是有效的。

@cubarco 能否给 meta 提个 pull request 修复一下

LovelyToaster commented 1 year ago

由于目前官方 Clash 团队还没有关注这个 Dreamacro/clash#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 ，而且验证是有效的。

@cubarco 能否给 meta 提个 pull request 修复一下

提高keep alive时间好像会导致部分连接不会断开，我改成3600后连接数经常200+，而且可以看见有很多相同连接存在几个小时，即使发出连接的设备已经关机，连接依旧存在

silverzhaojr commented 1 year ago

提高keep alive时间好像会导致部分连接不会断开，我改成3600后连接数经常200+，而且可以看见有很多相同连接存在几个小时，即使发出连接的设备已经关机，连接依旧存在

这个是预期的行为，上面有解释：https://github.com/vernesong/OpenClash/issues/2614#issuecomment-1665241053 。改成 30min 后，无效连接最多会存在 30min + 30min * 9 = 5hr。

最佳做法是等 Go 语言支持分开设置 KEEP_IDLE, KEEP_ALIVE_INTERVAL，KEEP_COUNT。

yyysuo commented 1 year ago

由于目前官方 Clash 团队还没有关注这个 Dreamacro/clash#2867 ，所以我直接改了下代码，将 TCP keep alive interval 设为了 1800s。大家可以测试看下，看看是否解决了这个问题：

https://github.com/silverzhaojr/clash/releases/tag/v1.18.0-fix-tcp-keep-alive

大佬能不能给一个meta版本的tun模式的内核编译成品呢

yyysuo commented 1 year ago

提高keep alive时间好像会导致部分连接不会断开，我改成3600后连接数经常200+，而且可以看见有很多相同连接存在几个小时，即使发出连接的设备已经关机，连接依旧存在

这个是预期的行为，上面有解释：#2614 (comment) 。改成 30min 后，无效连接最多会存在 30min + 30min * 9 = 5hr。

最佳做法是等 Go 语言支持分开设置 KEEP_IDLE, KEEP_ALIVE_INTERVAL，KEEP_COUNT。

https://github.com/MetaCubeX/Clash.Meta/issues/715#issuecomment-1707527012

貌似meta内核有大佬添加了配置，但是我不会配置。

silverzhaojr commented 1 year ago

貌似meta内核有大佬添加了配置，但是我不会配置。

根据这里的改动，应该是在 clash meta config.yaml 配置文件中增加一行：

# TCP keep alive interval，默认是 15s
keep-alive-interval: 15

将15改成1800，你可以试下是否生效。

注意要用这里的 alpha 版本：https://github.com/MetaCubeX/Clash.Meta/releases/tag/Prerelease-Alpha

yyysuo commented 1 year ago

在openclash中如何设置呢。

caneman commented 1 year ago

最新版的内核还没有修复这个问题吗？

LovelyToaster commented 1 year ago

最新版的内核还没有修复这个问题吗？

最新的alpha已经可以正常配置tcpalive时间了

xpn282 commented 11 months ago

我的iPhone和iPad一样的现象，连家里的Wi-Fi待机比蜂窝待机还要耗电多了。把OpenClash关掉，待机就正常了。。。我用最新的OpenClash和最新的Meta内核，在配置文件里添加keep-alive-interval: 1800，也没有任何效果。

现在的临时解决方案：在OpenClash的黑白名单里添加了iPhone和iPad，不让它们走OpenClash了，它们出国用小火箭app代替。。。

这个问题OpenClash什么时候能给予解决啊

dorty3541 commented 11 months ago

我的iPhone和iPad一样的现象，连家里的Wi-Fi待机比蜂窝待机还要耗电多了。把OpenClash关掉，待机就正常了。。。我用最新的OpenClash和最新的Meta内核，在配置文件里添加keep-alive-interval: 1800，也没有任何效果。

现在的临时解决方案：在OpenClash的黑白名单里添加了iPhone和iPad，不让它们走OpenClash了，它们出国用小火箭app代替。。。

这个问题OpenClash什么时候能给予解决啊

我测试了下，openclash 0.4.151-beta里已经有相关选项可以调整tcp keep-alive 间隔了

vernesong / OpenClash