为什么用 Cloudflare Tunnel 收口日韩港新美西入口
公网直连 Gateway 易被运营商封端口。Tunnel 把 TLS 放在 Cloudflare 边缘，远程 Mac 只维持出站连接，日韩港新美西可共用策略；低 RTT 区探测略紧，中继节点放宽失败阈值，减骨干闪断误杀。
反向代理与 Tunnel 的落地顺序
用 Nginx/Caddy 把 Webhook 与 Gateway 控制面拆到不同上游，避免大 Body 挤爆控制连接。顺序：Gateway 仅监听 127.0.0.1 → cloudflared hostname 指本机代理端口 → 再开 Webhook 并压测签名；透传 Host 与 X-Forwarded-*，防止回调 URL 写出内网地址。
- 环回：Tunnel 只打 127.0.0.1，勿绑局域网 IP。
- Webhook：代理层设 body 上限与慢客户端超时。
常见误区
面板全绿不等于路径正确——用公网 curl 打真实 Webhook，与平台控制台重放对照。
Webhook 与 Gateway 排错顺序
cloudflared 正常仍 502，多因本机未监听或地址错；200 无日志先看时钟与 chunked 是否被代理吞。日志按 401/413/429 切片更快。暴露面与探针分层见 Gateway 收敛与探针；Node/PATH 见 Node LTS 与权限排错。
16GB、24GB 与 M4 Pro 并发承载示意表
粗估示意，随通道与技能变化；多区并联宜入口机与重编译机分离。
| 档位 | Gateway+Tunnel | Webhook+多通道 | 与重编译错峰 |
|---|---|---|---|
| M4·16GB | 1 组稳态 | 单通道+轻回调 | 不宜同机大编译 |
| M4·24GB | 1–2 组 | 2 通道+中小 Body | 短时并行需限流 |
| M4 Pro | 多入口 | 多 Webhook+多技能 | 可与轻构建错峰 |
内存越大越扛突发回调；Tunnel 与重活拆开，降 Gateway 假死率。
一句话自检
502 查本机端口与 127.0.0.1；平台成功无日志则校时、看代理日志。
在 Mac mini 上，这套入口更省心
常驻 Tunnel 与反向代理需要低抖动与长稳运行，macOS 无人值守崩溃面小，Apple Silicon 待机功耗低，适合 7×24 Gateway；统一内存让多进程争用更平滑，Gatekeeper、SIP、FileVault 也降低入侵后的横向风险。
若要把本文链路跑在静音省电、长期成本更优的硬件上，Mac mini M4 是务实起点；可用 vpsdate 远程节点先验全链路，再按需升 M4 Pro 或多区并联。