 xmz7891
|
a53a3eee21
|
搬到 Lightsail：nginx 反代 + TLS + 公共 DNS + 后台口令改由服务器持有
== 架构（最终形态）==
用户 --HTTPS--> Cloudflare CDN --HTTP/HTTPS--> nginx --+--> 127.0.0.1:13245
yk.xxmxxs.top 13.54.30.196
中转只绑 127.0.0.1，公网只能经 nginx 进来 —— 少一个暴露面
（实测公网直连 :13245 返回 000，符合预期）。
== 这一轮加的 ==
1. **nginx 反代**（_build/setup_nginx.py）
Cloudflare 只能回源到特定端口（80/8080/443/2053…），
中转跑的 13245 不在列表里，所以中间必须有一层。
配置要点：
/download/ proxy_buffering on
/v1/ proxy_read_timeout 180s + **proxy_buffering off**
（长轮询要挂 60 秒；关缓冲，否则要等整个响应完
才吐给客户端，那就不是长轮询了）
2. **源站 TLS 证书**（_build/setup_tls_origin.py）
Cloudflare 的 SSL 模式是 Full(strict)，回源走 443，源站只有 80
-> 522。用 certbot 的 nginx 插件签了 Let's Encrypt 证书。
开着橙色云朵也能签：HTTP-01 挑战经 Cloudflare 回源到 80 能验证。
踩的坑：第一次用 example.com 当邮箱，Let's Encrypt 拒收保留域名。
3. **公共 DNS**（_build/fix_server_dns.py）
换域名之后 **服务器自己解析不了** yk.xxmxxs.top：
Lightsail 默认的内网解析器 172.26.0.2 还缓存着"不存在"（负缓存），
而 1.1.1.1 / 8.8.8.8 已经能解析。
后果不只是监测误报 —— 服务器上任何解析该域名的东西都会失败。
配上公共 DNS，内网那个降为后备（它对 AWS 自家服务更快）。
4. **监测与预案重写**（relay/monitor-lightsail.sh、rescue-lightsail.sh）
分两层探测，才能分清是哪一层坏的：
PRIMARY https://域名 用户实际走的
FALLBACK 127.0.0.1:13245 中转本身
PRIMARY 挂 + FALLBACK 好 -> edge 层 -> 动 nginx
两个都挂 -> core 层 -> 动中转
不区分的话只能瞎重启，而 edge 层的问题重启中转一万次也没用。
做法上也改了：不再"SSH 过去用嵌套 heredoc 现场打补丁"
（这一轮因此踩了五次转义/求值/百分号格式化的坑），
改成**本地写完整文件、整份上传**，能进 git 做版本管理。
5. **后台口令改由服务器持有**（_build/set_admin_password.py）
密码只写进 /opt/ykxmz-relay/data/admin_password.txt（600），
**不进代码、不进仓库**。本地脚本从环境变量或
_build/.admin_password（已 gitignore）读取。
这个仓库已经吃过一次"管理员密码硬编码进提交历史"的教训了。
6. **验证脚本**（_build/verify_admin_login.py）
第一版只看登录请求的状态码，结果"对的密码/错的密码/不带凭据"
**全是 302** —— 等于没测。改成看 cookie 再访问 /admin，
区分拿到的是登录页还是后台页。实测：
正确密码 -> cookie 1 条 -> 后台页
错误密码 -> cookie 0 条 -> 登录页
账号写错 -> cookie 0 条 -> 登录页
经 Cloudflare 域名 -> 后台页
== 其他修复 ==
* 下载响应有**两条** Cache-Control（nginx 和 relay 各发一条），
Cloudflare 遇到重复的缓存指令可能直接跳过缓存 -> 去掉 nginx 那条
* 监测探测地址跟着监听地址改（改入口必须回头看所有探测入口）
* curl 加 -L 跟跳转（certbot 加了 http->https 301）
* 旧服务器（随身 WiFi 那台）的服务全部停掉并取消自启，
但**没关机、没删文件** —— 保持可逆
全量回归 46 个阶段通过；594 个 Python 文件语法通过。
|
2026-10-08 23:07:45 +08:00 |
|
|
xmz7891
|
db669e2f40
|
修监测单元查错地址（改监听后它开始误报网站挂了）
把中转改成只监听 127.0.0.1（公网走 nginx）之后，监测单元还在查
http://13.54.30.196:13245/v1/health —— 那个端口已经不对公网开了，
于是它连续报"公网异常"，fails 涨到 2。
**差一点就是无限重启循环**：再失败一次它会启动紧急预案，
而预案的动作是"重启中转服务"，重启完再查还是 000，再救……
这是改监听地址时没想到的连带影响。教训写在这里：
**改一个服务的暴露方式时，必须把所有"探测它"的地方一起看一遍。**
== 改法 ==
监测地址改成"用户实际怎么访问"为准，域名优先、IP 兜底：
PUBLIC_URL=http://yk.xxmxxs.top 域名（经 Cloudflare + nginx）
FALLBACK_URL=http://13.54.30.196:80 绕过 CF 直连 nginx
只要有一个通就算健康。这样域名配好前靠兜底、配好后走真实路径。
== 顺带修的 ==
* monitor.log 属主还是 root（后来新建的），admin 写不进去
-> 再 chown 一次
* _build/check_lightsail.py 里的"公网"地址也要跟着改，
并且**故意保留**一项查 :13245（预期 000）用来确认
中转确实不再暴露公网
全量状态：三层地址、缓存头、监测、属主全部正确。
|
2026-10-08 22:41:33 +08:00 |
|
|
xmz7891
|
5fc2f97be7
|
2.1.3：搬到 Lightsail 真服务器 + 支持"没有证书的中转"
用户买了 AWS Lightsail（2G 内存 / 2 vCPU / 60G SSD / 公网 IP
13.54.30.196），中转从随身 WiFi 那台小机器搬过去。
== 为什么这次搬迁解决了一堆老问题 ==
原机器（Debian aarch64、460MB、走 4G）一直有几件搞不定的：
* 线路对 Cloudflare 隧道的 **7844 端口间歇性阻断**（443 通、7844 不通），
隧道每 3~10 分钟掉一次、公网跟着 530 —— 查了很久才从
cloudflared 自己的 precheck 里看清
* 只有 460MB 内存
* 会掉电硬挂（实测 2026-10-08 18:42 一次非正常关机）
新机器**有公网 IP**，中转直接监听，不经隧道、不过 7844。
实测公网延迟从 **1000~2000 ms 降到 1.1 ms**。
== 代码改动 ==
1. **relay.py 的 DATA_DIR 默认值不再写死**
原来是 /root/lanremote-relay。新机器上服务以 admin 普通用户跑
（它没理由要 root），而 /root 是 0700 —— 部署时直接
PermissionError: '/root/lanremote-relay'。
改成"本脚本所在目录下的 data/"，搬到哪都跟着走。
2. **客户端支持"没有证书的中转"**
新服务器是明文 HTTP（没签证书），而两个客户端原来都往 https 走：
* 手表端：裸 IP 会被强制补 https:// -> 永远连不上，
报的还是 SSL 错误，很容易让人白查半天证书
* Android 9+ 默认禁止明文流量，没 usesCleartextTraffic
请求会被系统直接掐掉
Windows 端本来就是对的（正则里把任意纯 IP 都当"用明文"）。
现在手表端规则和它一致，并加了 usesCleartextTraffic。
3. 清掉电脑端一段函数内的重复代码（return 之后还有一份拷贝，
缩进仍在函数体内所以不报错，但读起来很迷惑）。
== 新服务器上的部署 ==
/opt/ykxmz-relay/ 服务端（relay/admin/landing/showcase）
ykxmz-relay.service 监听 0.0.0.0:13245
ykxmz-monitor.service/.timer 每 60 秒查公网，连续 3 次不通就叫预案
rescue-lightsail.sh 四级阶梯抢救（重启中转 / 强杀重拉 /
查防火墙 / 重启整机[默认关]）
预案针对新架构重写过：原来围着隧道转（重启隧道、重施 MSS/MTU），
现在没有隧道，改成重启中转 + 查端口/防火墙。
全量回归 46 个阶段全部通过。
|
2026-10-08 22:29:56 +08:00 |
|