在本站中

本站是开源的，仓库在 yuxuetr/rustineverything。公网的 80 和 443 端口由 crates/gateway 里的网关（包名 rie-gateway）监听：它终止 TLS，把请求用明文 HTTP/1.1 转给本机 127.0.0.1:8080 上的 app 容器。app 那一侧（dioxus-server、axum、hyper）见 hyper 卷的本站的服务端路径。

这一部分的链接都指向提交 8729cfb（2026-10-28），行号以它为准。网关是一个独立的 workspace，只有 src/main.rs 一个源文件（221 行，含 3 个单元测试）。它的 Cargo.lock 锁的是 pingora-core / pingora-proxy 0.8.0、pingora-openssl 0.8.1、tokio 1.52.3，比本卷的 0.9.0 早一个版本；所以本部分讲两件事：网关今天跑的 0.8.0 代码路径，以及换成 0.9.0 会变什么。

1. 本站的网关：main 建两个服务，443 端口 TlsSettings::intermediate 加 enable_h2，80 端口只在 request_filter 里写 301；AppGateway 的 upstream_request_filter 覆盖 X-Forwarded-For 并删掉 Forwarded，response_filter 补安全头、不碰 CSP，都在拷贝上实测过。四个问题逐个复现：HTTP/1 连接发过一个请求后空闲不再超时（每条约 68 KiB，2000 条就超过容器的 128 MiB），h2 连接只握手不发前言同样不超时；0.8.0 在复用连接失败时重试 POST；cargo update 一次就会拉到让 0.8.0 panic 的 tokio 1.54；默认 300 秒宽限期比 docker 的 10 秒长，每次重启都要等到被 SIGKILL。空闲、POST 重试和宽限期三条各给出网关代码里的最小改法并验证，tokio 那一条只能靠锁文件挡。另外两处：锁文件停在 pingora-core 0.8.0，错过了 0.8.1 给 h2 默认上限的安全修复；源码注释里的「kill -HUP 重载证书」实际会直接结束进程。最后把拷贝升级到 0.9.0：没有编译错误，行为差别逐条实测。

flowchart TB
  web["浏览器"] --> tls[":443 TLS + h2"]
  web --> plain[":80 明文"]
  plain --> redir["HttpToHttps：301"]
  tls --> gw["AppGateway"]
  gw --> app["app :8080"]
  app --> hyper["hyper 卷 11"]