Nginx

如果你已经看过 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，也不用自己处理常见代理应用需要的周边能力。 ...

Cloudflare 开源 Pingora 之后，很多人会问：它能不能替代 Nginx？如果问题只是“能不能把请求转发到后端服务”，答案是能，而且几十行 Rust 就够了。但 Pingora 不是一个读取 nginx.conf 的服务器，它更像一套用来写代理、网关和网络服务的 Rust 框架。 这篇只做一件事：用 Pingora 写一个最小反向代理，让 http://127.0.0.1:6188/ 转发到本机的 127.0.0.1:3000，然后把这个二进制按服务方式部署起来。 本文示例版本核对时间：2026-05-17。示例使用 pingora = "0.8"。 先看等价的 Nginx 配置 如果用 Nginx，最小反代大概长这样： server { listen 6188; location / { proxy_pass http://127.0.0.1:3000; proxy_set_header Host $host; proxy_set_header X-Real-IP $remote_addr; proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for; proxy_set_header X-Forwarded-Proto http; } } Pingora 的思路不一样。你不是写配置块，而是实现 ProxyHttp trait：请求进来以后，代码决定它要转发到哪里，转发前要改哪些请求头，最后日志怎么记。 创建项目 cargo new mini-pingora-proxy cd mini-pingora-proxy Cargo.toml： [package] name = "mini-pingora-proxy" version = "0.1.0" edition = "2021" [dependencies] async-trait = "0.1" env_logger = "0.11" log = "0.4" pingora = { version = "0.8", features = ["proxy"] } 这里用的是 pingora 聚合 crate，并启用 proxy feature。Pingora 没有默认打开所有能力；如果后面要做负载均衡，需要再启用 lb；如果要监听 HTTPS 或连接 HTTPS upstream，还要选择对应的 TLS feature，比如 openssl、boringssl、s2n 或实验性的 rustls。 ...

Cloudflare 公开 Pingora 时，最抓眼球的数字是：在相同流量下，新的代理系统比旧系统少用了约 70% CPU 和 67% 内存。 看到这个数字，很多人的第一反应可能是：是不是 Nginx 不行了？是不是 Rust 天生就比 C 快很多？ 都不是。 我们真正要回答的是：Cloudflare 为什么会觉得原来的 NGINX/OpenResty 代理不够用了？Pingora 又改掉了哪些最贵的地方？ 后面就顺着这个问题往下走。先看 Pingora 是什么，再看 Nginx 在普通场景里为什么很好用，最后再看 Cloudflare 这种规模下，连接池、线程模型和业务逻辑会怎样把成本放大。 可以先带着三句话往下读，后面会一层层展开： Cloudflare 替换的是他们内部深度改造过的 NGINX/OpenResty 代理，不是说 Nginx 在所有场景下都慢。 Pingora 开源版更像“用 Rust 写代理服务的工具箱”，不是一个直接读取 nginx.conf 的 Nginx 替代品。 重点不是“Rust 打败 Nginx”，而是连接复用、线程共享和复杂代理逻辑这些具体问题。 1. Pingora 不是一个新的 Nginx 如果你平时用 Nginx，可能会自然地把 Pingora 想成“另一个服务器软件”。但这样理解会有点偏。 Pingora 更像一套用 Rust 写代理服务的工具箱。它帮你处理连接、TLS、HTTP 协议、负载均衡、连接池、优雅升级这些通用能力；你的业务逻辑则写在 Rust 回调里。 它不是单个二进制 Web 服务器，而是一组 crate： crate 作用 pingora-core 底层协议、服务运行、监听器、连接器、优雅升级 pingora-proxy HTTP 代理生命周期和 ProxyHttp 回调接口 pingora-pool 高并发连接池 pingora-runtime Tokio runtime 封装，支持 work-stealing 与 no-steal 模式 pingora-load-balancing 负载均衡、健康检查、选择算法 pingora-cache / pingora-memory-cache 缓存相关能力 这些名字不用急着都记住。先有一个印象就够了：Pingora 把“写代理服务”拆成了一组可以组合的 Rust 库。 ...

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，承载两个站点： ...