@TcDhl 大佬，这个是完全自己写的平台吗？

@yaocf pyrogram 的代码注释对这个方法的说明就是：This is the equivalent of clicking an inline button containing callback data.

找到了，可能是算是新手吧，api 文档中的 tg 专业名词太多了。
https://docs.pyrogram.org/api/methods/request_callback_answer

如题示例：
```python
await app.request_callback_answer(_id, message.id, "checkin", 0)
```
最后的 timeout 参数不知道该怎么填，不过效果已经达到了。

dart 是有反射的，只是 flutter 没有，可能是谷歌被 java 时代的反射搞怕了，flutter 禁用 dart 之后，世界一下子就安静了。

嗯，之前理解错了，unix 可以设置的是缓冲长度（-I length TCP receive buffer length ）。

至于为啥要一个定长日志，原因如下：那个进程的输出文本产生的特别快，如果直接怼到系统 log ，会导致其他进程的 log 被冲掉，但是，如果在 procd 中将输出信息重定向到文件，又担心那个文件会无限制增长。用 cron 倒是可以做到效果，但是总感觉不是很完善。

dynv6 恢复了。

while [ `/usr/bin/curl -s -o /dev/null -w "%{http_code}" "https://dynv6.com"` -ne 200 ];
do
echo -e "$(date) \t Still down! waiting..."
sleep 300s
done
echo -e "service was online!"
/usr/lib/mylibs/noticeMeByMail "service was online!"

自动检测。

已经 72 小时了。从周六那天就开始 500 了。

找到原因了，是防火墙区域设置里的 nat （ Ip 动态伪装）没开。
但是现象很奇怪，按理说，请求包的目的地址是 172.16.0.9 ，根据路由表它是可以正常找到路由，发到 wg0 的，wg0 应该也是可以从设置的 AllowIps 找到中继网络 B 的，中继网络 B 可以很容易地找到正确的对端 172.16.0.9 ，顶多是回来的时候，因为请求源地址（响应的目的地址） 10.0.0.106 不在 wg0 接口的网段，所以响应包会被丢弃。可为什么，我从 172.16.0.1 那台中继网络 B 中，并没有看到任何数据包？？？

@yaocf
可能是使用 cat <<EOF EOF 写入配置文件的原因，纠正一下，不需要加\。原先的配置文件应该是正确的。

@crystom 恩，谢谢，好不容易编译出了带调试模式的 nginx，看了下调试日志，问题找到了。配置文件中所有的 $ 换成 \$ 就行了。不知道为什么要转义一下才能用。按理说 nginx 的配置文件读取模块应该会考虑到这个吧。

新的配置文件如下，也希望可以帮到有同样问题的小伙伴。

user root;
worker_processes auto;
pid /run/nginx.pid;
include /etc/nginx/modules-enabled/*.conf;
error_log /var/log/nginx/error.log;

events {
worker_connections 1024;
multi_accept on;
}
http {
tcp_nodelay on;
log_format main '\$remote_addr - \$remote_user [\$time_local] \$status '
'"\$request" \$body_bytes_sent "\$http_referer" '
'"\$http_user_agent" "\$http_x_forwarded_for" "\$host\$request_uri"';
access_log /var/log/nginx/access.log main;
server {
listen 80;
location ~/\.well-known* {
#root /usr/lib/mylibs/acme_tiny;
alias /usr/lib/mylibs/acme_tiny/.well-known/;
autoindex on;
}
location ~/* {
rewrite ^(.*) https://\$host\$request_uri break;
}
}
}