速读#
这篇把 Git、Docker、Nginx、Cloudflare、后端和数据库放回一条请求链路里看。读它不是为了学新命令，而是把“我会一堆技术”改成“我知道每层在系统里站哪”——排障时能按层收缩范围，也诚实标出还没亲手做过的缺口。
请求经过的每一层#
用户访问 https://s1oop.bbroot.com/2026/06/hello：
| 站 | 做了什么 | 用到的技术 | 面 |
|---|---|---|---|
| DNS | 域名 → CF 边缘 IP，非源站真实 IP | Cloudflare DNS | 可达 |
| CF 边缘 | SSL、WAF、缓存判断 | Cloudflare | 防护 |
| Tunnel | cloudflared 出站，源站零入站 | Cloudflare Tunnel | 可达 |
| Nginx | 按域名分发，传转发头 | Nginx 反代 | 可达 / 防护 |
| 后端 | 业务处理 | FastAPI / Spring Boot | — |
| 数据库 | 落库 | SQLite / MySQL | 数据 |
| 返回 | 原路 HTTPS 回用户 | HTTPS 证书链 | 防护 |
dig s1oop.bbroot.com +short # 常见返回 CF 边缘 IP串起来之后：按「面」想，不按「技术」想#
可达： DNS 藏真实 IP，Tunnel 把入站翻成出站，Nginx 在最内侧按域名分发——从外到内一层比一层收紧。 防护： WAF 在边缘挡通用攻击，ufw 和 fail2ban 在主机挡端口和暴力尝试，HTTPS 在传输层挡窃听——分层各挡一类，谁也替不了谁。 可观测： 不出现在链路图上，却盯着整张图——哪吒看整机指标，journalctl 看单个服务的死因。 守护： 也不在链路上，但链路上每个进程活着都靠它——systemd 把「崩了」变成「崩过」。
加新服务时，顺序反过来了：先过可达 / 防护 / 守护 / 可观测，再动手部署——不再「先装再说」。
这张图最大的用处：排障时按层收缩#
「网站打不开」不是一个问题，是七个可能的问题。有了这张图，排查从瞎猜变成按层收缩：
| 检查 | 命令 / 动作 | 排除哪层 |
|---|---|---|
| 域名还解析吗 | dig 域名 +short | DNS |
| 边缘有响应吗 | curl -I https://域名，看返回头 | CF 边缘 |
| 隧道还连着吗 | systemctl status cloudflared | Tunnel |
| 源站服务活着吗 | 服务器上 curl 127.0.0.1:端口 | Nginx / 后端 |
| 进程为什么死的 | journalctl -u 服务名 -e | 后端 / 数据库 |
从两端往中间夹：外侧 dig/curl 验证公网视角，内侧回环 curl 验证服务本体，问题一定卡在两个「通」之间的那层。不懂链路时，每次故障都是全新恐慌；懂了之后，故障只是二分查找。
还有一个前提容易被跳过：CF 缓存命中时，请求根本不会到源站。排障前先看响应头里的 cf-cache-status，确认这次请求真的回源了——否则你会在源站日志里，等一个永远不会出现的请求。
诚实缺口：负载均衡与水平扩展#
这张图大部分串通了，真正的负载均衡和水平扩展还没亲手做过——仍是单机。对大厂架构做过纸上对照，但纸上得来的不算数。
缺口标出来，不假装通了。
这篇不是新知识，是组织方式变了：同样的零件，按系统看 vs 按知识点看，深度完全不同。