Caddy
作为唯一公网入口，负责 TLS、自动证书和基础边缘协议处理。
项目目标
用一个边界清晰的真实项目学习 Pingora：Caddy 负责公网 HTTPS 与证书自动化，sitegate 负责静态内容、路径安全和基础观测能力。
当前状态
应用侧 V1 在一天内形成可运行闭环，并完成真实公网域名下的 HTTPS、静态资源、健康检查、自定义 404、路径安全和结构化访问日志验证；阅读事件端点与浏览器逻辑已实现，真实流量下的长期验证仍在后置。
1 天应用侧 V1 完成最小闭环
2 层Caddy 管 TLS，Pingora 管应用边界
0 Cookie阅读事件不使用 Cookie
系统边界
sitegate
处理静态文件、健康检查、路径规范化、访问记录和站内事件。
公开内容
只包含作品集和经过脱敏的工程案例，不直接暴露私人工作台。
观测数据
访问日志与阅读事件分开记录，用于理解站点访问与页面阅读情况，不建立跨站访客画像。
隐私与安全取舍
- 阅读事件只记录页面、来源类别和首次达到的停留/滚动阈值。
- 阅读事件尊重浏览器的 Do Not Track 与 Global Privacy Control 信号。
- 不记录 Cookie、请求正文或完整查询参数。
- bot 分类仅用于分析，不作为访问控制依据。
- 未找到的静态路径返回 404，不提供目录列表或隐式 SPA fallback。
为什么不用现成静态托管
上线个人站本身并不需要自研网关。选择 Rust 与 Pingora，是为了在低风险、可验证的场景中理解真实反向代理、日志边界和公网运行约束，同时让项目本身成为可展示的工程证据。
项目刻意不扩张为通用网关：认证、插件系统、管理后台和自研 ACME 均不属于 V1。
公网部署带来的真实问题
- 应用程序、TLS 入口、DNS、备案状态和云厂商接入策略属于不同责任域，需要分别取证。
- 公网不可达时，通过本地健康检查、其他网络交叉验证、HTTP/TLS 行为和供应商工单排除应用故障。
- 这类问题不能靠继续改代码解决；闭环包括判断何时停止编码并转向外部支持渠道。
具体云厂商、地址、工单和部署参数不在公开页面展示。
项目价值
sitegate 不是为了证明静态站必须自研。它验证的是：面对一个陌生基础设施组件，我能控制范围、做出第一版、放到真实公网，再用日志和故障证据理解系统边界。