Pingap

在上一篇里，Marinara 跑在 127.0.0.1:7860，通过 Pingap 用 http://IP 对外提供访问。这样能用，但有一个难受的地方：Basic Auth 的账号密码是在明文 HTTP 里传的。所以目标很明确：给它配上 https://marinara.icyyan.com。 要做的事情拆开来就两件：证书从哪来，证书怎么挂到反向代理上。好消息是这台服务器上已经有两个站点（cloudside.icyyan.com、silly.icyyan.com）跑着 HTTPS，整套体系是现成的——新站点照抄就行。这篇文章把整个过程走一遍，包括中间踩掉的几个坑。 1. 先看现成的体系长什么样 照抄之前先弄清楚抄的是什么。服务器入口是 Pingap，HTTPS 这一块的结构是： 443 端口只监听一次，靠 SNI 分流。SNI 是 TLS 握手时客户端告诉服务器「我要访问哪个域名」，服务器按这个域名选对应的证书、再按域名找到对应的 location 转发。所以多个 HTTPS 站点可以共用同一个 443。 每个域名一张 Let’s Encrypt 证书，统一放在 /etc/letsencrypt/live/<域名>/ 下，都是 certbot 签的。 签证书用的验证方式是 dns-aliyun 插件，这是整个过程里最关键的一环，值得单独说。 2. 为什么用 DNS-01 挑战 CA 签证书之前，必须先确认「你确实控制这个域名」，这个确认动作叫挑战（challenge）。最常见的 HTTP-01 挑战是让 CA 从公网访问 http://<域名>/.well-known/... 下的一个文件——这要求域名已经解析到服务器、80 端口可用。 DNS-01 换了一条路：只要能在这个域名的 DNS 里写下一条指定的 TXT 记录，就证明你控制了整个域。阿里云的 DNS 有 API，certbot 的 dns-aliyun 插件会自动完成「写 TXT 记录 → 等它生效 → 让 CA 来查 → 删掉记录」的全过程，人不用插手。 ...

如果你已经看过 Pingora 的最小反向代理示例，很容易产生一个后续问题：生产环境是不是也要自己继续写配置解析、证书加载、日志、热更新和管理界面？通常不需要。Pingap 就是基于 Pingora 做好的反向代理应用，它更接近一个可以直接部署的 Nginx 替代方案。 这篇文章只讲 Pingap：怎么安装，怎么写一个最小反代配置，怎么加 HTTPS，怎么用 Docker 或 systemd 部署，以及从裸 Pingora 或 Nginx 迁移过来时有哪些容易忽略的坑。 本文示例版本核对时间：2026-05-17。示例固定使用 Pingap v0.13.4。实际部署前建议再看一次官方 GitHub Releases 和文档，因为 Pingap 还在快速变化。 Pingap 和 Pingora 的关系 Pingora 是框架，你通过 Rust 代码实现代理逻辑。Pingap 是应用，它把常见反向代理能力包装成 TOML 配置和 Web 管理界面。 一个最小 Pingap 配置大概长这样： [upstreams.app] addrs = ["127.0.0.1:3000"] [locations.app] host = "app.example.com" path = "/" upstream = "app" enable_reverse_proxy_headers = true [servers.http] addr = "0.0.0.0:6188" locations = ["app"] 这段配置和一个最小 Pingora 代理做的是同一件事：监听 6188，把匹配 app.example.com 的请求转发到 127.0.0.1:3000。差别在于，你不用实现 ProxyHttp，也不用自己处理常见代理应用需要的周边能力。 ...

0. 背景与动机：为什么要替换掉 Nginx？ 在过去很长一段时间里，本站点的静态文件托管（Hugo）以及动态服务反代（SillyTavern）一直由 Nginx 承担。Nginx 久经考验、极其稳定，堪称业界标杆。但随着系统架构的演进和统一网关管理的考量，我们开始寻求更现代化的反向代理方案，并最终将目光投向了 Pingap。 为什么选择 Pingap？ 现代化的底层基石：Pingap 基于 Cloudflare 开源的 Pingora 框架构建，采用 Rust 编写。Pingora 在 Cloudflare 内部已经受了万亿级请求的考验。得益于 Rust 的内存安全特性，它从根本上规避了传统 C/C++ 网关常见的内存越界和崩溃风险。 更直观的配置模型：Nginx 的配置语法虽然强大，但指令的上下文和隐式执行顺序往往让人头疼。Pingap 采用了基于 TOML 的声明式配置，将 Server、Location、Upstream 和 Plugin 彻底解耦，配置的心智模型更加清晰，更利于后期的维护与扩展。 原生的高级特性支持：Pingap 对 HTTP/1.x、HTTP/2、WebSocket、gRPC-web、证书动态加载和插件化网关能力支持更直接。需要注意的是，HTTP/3/QUIC 这类能力应以当前官方 release 和文档为准，迁移生产入口时不要默认假设已经完整可用。 本次实战的核心目标：先在隔离端口上把新代理跑起来并完整验证，再用一次原子切换无缝替换 Nginx，全程保留 Nginx 配置以便出现问题时能够秒级回滚。 通过这种“先验证后切换”的安全策略，我们最终实测的切换中断窗口仅为 174 ms，线上流量几乎无感。 2026-05-17 复核：我重新 SSH 到服务器核对了一遍真实状态。当前服务器仍运行 pingap 0.13.2，pingap.service 使用 daemon 模式，Hugo 静态文件由 darkhttpd 承载。本文以下配置以服务器现状为准；新装环境可以再按最新 release 调整。 1. 起点：现状盘点 服务器：阿里云 ECS（Alibaba Cloud Linux 3 / RHEL 兼容），跑 Nginx 1.20.1，承载两个站点： ...