Cubarco

+1 rclone挂载webdav到群晖上，可以用命令行读写，但是群晖的File Station只能读，不能写

@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的成因。

> 可以试试让所有会保持长连接的地址绕过内核，我的小米手机也出现了待机耗电异常的情况，发现待机时持续未知原因的唤醒，再将Google FCM和小米push绕过内核后，情况立刻消失 @LovelyToaster 请问mipush绕过内核走的是IP白名单吗？ 网上没找到mipush的ip段，可否提供下？ update: 好像不需要，直接所有china ip都绕内核就好了；只有apple和fcm的国外ip段需要单独处理

> 其实好像是只要走内核的连接都会造成我的手机唤醒耗电，我把mipush和FCM绕过内核让情况消失的前提是我对于手机的大部分应用回到后台后链接会被关闭，而且中国ip段绕过内核 刚才发现了这个issue：https://github.com/v2ray/v2ray-core/issues/2564 测试了一下，走clash内核(direct)的长连接，每15秒都有个keep-alive包从clash内核发到客户端： ```plain 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...

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

我给clash加长了keep-alive心跳间隔时长（默认是15s），并经过吃灰iPad一个多月的待机验证，观测到待机耗电确实是在减少了。至少对我来说clash的续航问题应该是这个[issue](https://github.com/Dreamacro/clash/issues/996)导致的。 我的解决方案是在Clash.Meta上简单修改了一下keep-alive的心跳间隔：https://github.com/cubarco/Clash.Meta/commit/e5a0e6c0abc755391ee25f83cd4604715b96b4d5 。有异常耗电问题的朋友可以尝试下，[release](https://github.com/cubarco/Clash.Meta/releases/tag/v1.13.2-custom)里面有预编译的binary。

昨天尝试在有翻墙环境的网络下，用nb4a的*直连模式*，还有clashmetaforAndroid的*直连模式*，两者的dns都走系统默认；发现新打开的应用前几个网络请求都会卡3秒中，这个issue提到的：telegram的嵌入式浏览器（edge）第一个dns卡3秒，应该也是这个现象的一部分。 只有surfboard不会，不管开没开直连模式，新打开的应用的前几个请求都在合理延迟内正常响应

看了下，限制是在UploadMediaRequest的inputMediaDocumentExternal限制大小是20MB。 那么能否支持使用自建Bot API上传大文件？或者缓存本地后用send_file、upload_file上传呢（确实会有额外损耗）？