test: add reverse proxy deployment check

PERFORMANCE.md

@@ -23,6 +23,9 @@ python3 scripts/verifyLinux.py --load --tls --duration 30s \
 python3 scripts/verifyLinux.py --load --tls --duration 30m \
   --concurrency 128 --idle 512 --count 1 \
   --output performance/linuxSoakTLS-30m.json
+
+# Linux 上用 Nginx 反向代理接入 native TLS 服务，检查 Keep-Alive、超时和优雅关闭
+python3 scripts/verifyProxy.py
 ```
 
 可通过 `--concurrency 1,32,128` / `--idle 128,1024` 调整矩阵；传空字符串可跳过对应场景。工具只监听本机随机端口，每个场景启动独立服务进程，并在结束后关闭客户端、检查连接排空、关闭服务。响应状态、完整响应体、requestId 或传输错误均计入失败，不能把快速返回的错误页算成成功吞吐。
@@ -75,6 +78,8 @@ Linux arm64 容器使用 Go 1.25.14、GOMAXPROCS=4 运行 3 秒矩阵，见 [tls
 
 Linux arm64 的 30 秒高并发回归见 [linuxSoak.json](performance/linuxSoak.json) 和 [linuxSoakTLS.json](performance/linuxSoakTLS.json)：两份报告均使用 128 并发流量和 512 条空闲连接，所有场景错误为 0；native 非 TLS 约 146,614 req/s、TLS 约 149,720 req/s，空闲连接堆增量分别约 2.57 MiB 和 4.47 MiB，FD 均由 7 增至 519 并回到 7，goroutine 均回到启动附近。
 
+目标 Linux amd64 服务器的 30 分钟 TLS 验收使用 1 个 CPU、1 GiB 内存的隔离 Docker 容器完成：net/http 约 11,865 req/s，native 约 13,098 req/s，两个流量场景均为 0 错误；native 的 P95/P99 为 44.040/52.429 ms。512 条空闲 TLS 连接时，native 服务端堆增量约 4.50 MiB（约 9,215 B/连接），文件描述符由 7 增至 519 后回到 7，goroutine 和连接均正常回收。原始报告保存在服务器的 `performance/linuxServerSoakTLS.json`。
+
 `BenchmarkTransportTCPApplicationRequest/{nethttp,native}/concurrency{1,32,128}` 使用同一测试入口、客户端、应用与响应检查。原先独立的 `BenchmarkNativeApplicationRequest` 已合并，避免两个入口配置漂移。`verifyPerformance.py` 会一并运行。
 
 并行 benchmark 的 **`ns/op` 是总经过时间除以请求数，反映吞吐成本，不是单请求延迟**。`B/op` / `allocs/op` 统计同一进程中的客户端与服务端总分配。此前报告的 native 15.4–16.7 µs/op、约 7.8 KB/op、100 allocs/op 应按这个含义理解，不能作为服务端延迟或独立内存指标。