历史记录：修复 fichil.com 的 VPS 连接拒绝问题

历史架构说明： 本文记录的是 fichil.com 早期运行在 VPS 与 Nginx 上时的排障过程。当前生产站已经迁移到 ChatGPT Sites，不再使用这里描述的服务器发布和回滚路径。现行架构见用 AI 开发与运维 fichil.com。

当时的故障表现是浏览器直接返回连接拒绝。这个错误发生在 HTTP 应用内容之前，因此排查重点不应先放在 Hugo 模板或文章文件，而应从网络与监听边界开始。

连接拒绝首先说明什么

连接拒绝通常表示域名已经解析出目标地址，网络请求也到达了对应主机，但目标端口没有进程接受连接，或被主机侧规则明确拒绝。

它与 DNS 解析失败、连接超时和 Nginx 返回 4xx/5xx 不同。先区分传输层现象，可以避免在站点内容上浪费时间。

按由外到内的顺序检查

当时使用的检查顺序是：

1. 确认域名解析到预期 VPS；
2. 从外部探测 80/443 端口；
3. 在主机上确认端口监听与占用进程；
4. 检查防火墙和云平台安全规则；
5. 检查 Nginx 服务状态与错误日志；
6. 最后核对站点配置、证书和 Hugo 构建目录。

这个顺序让每一步都回答一个明确问题：请求有没有到主机、端口有没有服务、代理有没有加载配置、静态文件是否存在。

恢复后的验证不能只看首页

服务恢复后需要从外部再次验证 HTTP 与 HTTPS、重定向、中文和英文入口、静态资源以及一个具体文章路径。主机本地 curl 成功并不能证明公网 DNS、防火墙和证书链都已经正常。

同时应记录实际监听进程、加载的 Nginx 配置和站点根目录，避免“修改了文件但运行服务没有使用该文件”的配置漂移。

这篇历史记录仍然有用的部分

虽然 fichil.com 已不再使用 VPS 部署，但排障顺序仍适用于自管服务器上的连接拒绝：先证明网络和监听状态，再进入代理配置与应用内容。

需要避免的是把这套旧架构误当成 fichil.com 当前的发布方式。现在的生产版本通过精确提交、Sites 版本和 /version.json 进行验证与回滚。