See: https://wiki.archlinux.org/title/WireGuard

After resolving a server's domain, WireGuard will not check for changes in DNS again.
If the WireGuard server is frequently changing its IP-address due DHCP, Dyndns, IPv6, etc., any WireGuard client is going to lose its connection, until its endpoint is updated via something like wg set "$INTERFACE" peer "$PUBLIC_KEY" endpoint "$ENDPOINT".
Also be aware, if the endpoint is ever going to change its address (for example when moving to a new provider/datacenter), just updating DNS will not be enough, so periodically running reresolve-dns might make sense on any DNS-based setup.
Luckily, wireguard-tools provides an example script /usr/share/wireguard-tools/examples/reresolve-dns/reresolve-dns.sh, that parses WG configuration files and automatically resets the endpoint address.
One needs to run the /usr/share/wireguard-tools/examples/reresolve-dns/reresolve-dns.sh /etc/wireguard/wg.conf periodically to recover from an endpoint that has changed its IP.
One way of doing so is by updating all WireGuard endpoints once every thirty seconds[6] via a systemd timer:

/etc/systemd/system/wireguard_reresolve-dns.timer

[Unit]
Description=Periodically reresolve DNS of all WireGuard endpoints

[Timer]
OnCalendar=*:*:0/30

[Install]
WantedBy=timers.target


/etc/systemd/system/wireguard_reresolve-dns.service

[Unit]
Description=Reresolve DNS of all WireGuard endpoints
Wants=network-online.target
After=network-online.target

[Service]
Type=oneshot
ExecStart=/bin/sh -c 'for i in /etc/wireguard/*.conf; do /usr/share/doc/wireguard-tools/examples/reresolve-dns/reresolve-dns.sh "$i"; done'

Afterwards enable and start wireguard_reresolve-dns.timer

好东西 感谢楼主

@shunia 高精 ip 的话，常用的 ip 变化没那么频繁.一般一周 一个月更新一次就行 pc 也可以写一个 crontab 来自动化执行

@Misakax 😂 我暂时只适配了 dler 的 如果不是 就得自己改一下 proxies- providers 了

@amamiya 抽空我试一下

@isad 这是自己做的路由，直接按地区走机场的专线落地对应地区了。 至少少了国内出国这部分线路。 虽然落地后也有类似的问题，不过只要落的不差太多，就会就近路由到对应 AS 的

@sss15 clash 的话官方有一篇 wiki 讲了所有的配置 https://github.com/Dreamacro/clash/wiki/Configuration/99a5f8b699179e49504864b70f312cffb397a31b

楼主可以看看 ipinfo.io 他们家的数据库

@sss15 clash 的配置我还没写。mmdb 的话倒是通用的，但是分流规则啥的实际上写法还是和 quantmultx 略有区别。后续应该还是要再写一个模版 定时生成主流配置

小米的 magsafe 充电宝，平时就用来当底座用，应急还能当个外接电池

我的国外去区的号码是日区的 id，绑定了 jcb

其实要求也没有上面要的那么吓人，最近比较缺人，实际上组里也有不少从别的方向转来的人，没有音视频基础，想做这个方向的也可以试试看

@wohenyingyu02 其实原生不滥用用 fcm 也能收到消息，但是国内魔改的 rom 就没办法了，对于这些 rom，实际上就算你滥用也是没办法

@wohenyingyu02 @honeycomb 其实国产 ui 这样子，你滥用如果不在白名单里耶收不到消息。。 原声不滥用也收得到消息， 最后实际上滥用是坑了用户。。。 真正的提升是在那些有后台限制，但是限制的不是那么严格的定制 ui 上，滥用权限可以提高一部分消息到达率和实时性

目前我也没看到过哪个强社交应用敢在 android 上仅仅就用 GCM 推送，都会辅助有自家的消息推送服务在，所以 @wohenyingyu02 对于特定的需求一定会有特定的解决办法，毕竟这个公约刚刚起草出来，肯定不能对所有的应用类型逗非常适用，但是对公约的前景我还是看好的。 但是我认为真正的结局办法还是得提供一个统一的国内推送平台，不过这种短期看起来也不现实，各家有各家的利益，各自为政，之前华为的公约 泰尔实验室的会议，这几次弄下来感觉 BTA 那边并没有行动的苗头。。再等等看吧

首先微信并不使用 GCM 推送，而是使用 GCM 作为辅助唤醒通道，这点根 Line whatsapp 基本上是一样的，现在改用 fcm 了，透过透传机制辅助唤醒自家的推送服务，从而达到推送效果，而且微信和 qq 这几个版本最大的黑点我不认为在推送上，他 activity 杀掉后后台自动重启才是最坑的事情，最近微信和 QQ 的推送应该还算是国内能保证推送到达及时性并且耗电也不算很高的

LineageOS

google play 上的確可以，國產商店的話，好像沒什麼辦法了把。 不過 ndk 的 abiFilters 倒是可以限制某些特定處理器的安裝

@andyL 有，并没有什么用，后悔摸了整整一个月