背景
HTTP 代理在企业的安全审计、流量管控、缓存加速、访问控制等场景中是基础设施级组件。市面可选方案包括 Squid、Nginx、HAProxy、Traefik、Envoy、Apache Traffic Server、商业设备等，光看基准数字和官网话术很难选出真正适配自身业务的产品。
以下 15 项技术评估维度 是我在多个选型项目中沉淀的 checklist，覆盖协议、性能、可观测性、安全、运维五个域。每次选型对照打一遍分，基本不会漏坑。
一、协议与兼容性（3 项）
1. HTTP/1.1 完整性与 RFC 合规
不只是「支持 HTTP/1.1」，要核实：
- 是否完整支持
CONNECT方法（TLS 隧道代理） Keep-Alive复用是否可配置（连接池参数）Transfer-Encoding: chunked是否正确处理Upgrade头（WebSocket 场景）是否透传
踩坑案例：某商业代理在长连接池满时静默断开未完成的 chunked 响应，导致下游 SDK 解析 hang 死。
2. HTTP/2 & HTTP/3 上游能力
企业对外流量中 HTTP/2 已成主流（API 网关、gRPC 场景），HTTP/3（QUIC）也在快速渗透。选型时要区分：
| 能力 | 必须 | 建议 |
|---|---|---|
| 下游客户端 → 代理 支持 HTTP/2 | ✅ 正向代理 | --- |
| 代理 → 上游服务器 支持 HTTP/2 | ✅ | --- |
| 代理 → 上游 HTTP/3 | ❌ 非必须 | ✅ 选配 |
| HTTP/2 HPACK 压缩 | ✅ | --- |
| gRPC 透明代理（Content-Type 识别） | --- | ✅ 大厂路线 |
3. TLS 全生命周期覆盖
- 支持的 TLS 版本：1.2 最低，1.3 必须
- 证书管理：是否支持动态加载（不重启）、ACME 自动续签、mTLS 双向认证
- SNI 路由能力：基于域名分发到不同后端
- OCSP Stapling、Session Resumption 支持
二、性能与可扩展性（4 项）
4. 并发连接与吞吐上限
不要只看官方宣称的「百万并发」。要问：
- 单实例在 4C8G 下的实测 RPS（每秒请求数）
- 长连接保持与短连接新建各自的极限
- 是否支持
SO_REUSEPORT多进程/多线程模型 - 连接数上涨时的延迟曲线（线性还是指数退化）
建议 ：要求厂商提供其方案在 类似你生产流量 pattern 下的压测报告，而非 benchmark 最优场景数据。
5. 连接池与管理策略
企业级代理需要精细控制连接复用：
- 上游连接池最大/最小/空闲超时是否可配
- 是否支持慢启动（slow start）避免冷连接打垮上游
- 是否支持熔断（circuit breaker）、重试策略（幂等请求安全重试）
- WebSocket 连接的生命周期管理是否独立于普通 HTTP 池
6. 缓存层性能策略（如涉及）
如果代理兼做缓存 / CDN 回源层：
- 缓存驱逐策略：LRU / LFU / TTL 混合
- 缓存命中率与存储介质联动（内存 vs SSD vs 共享存储）
- 是否支持 Range 请求的缓存分片
- PURGE / BAN 接口是否支持精确或正则匹配
7. 动态配置与热加载
- 路由规则、上游后端、TLS 证书是否可热更新
- 配置热加载过程中的连接是否无损 drain
- API 驱动的配置管理是否成熟（CRUD + watch 机制）
- 是否有配置版本回滚支持
三、可观测性（3 项）
8. 日志分级与结构
- 访问日志输出格式是否可自定义（JSON / LTSV / 模板）
- 是否支持日志采样（降低高流量场景的磁盘开销）
- 错误日志是否区分 WARNING / ERROR / CRITICAL
9. 可观测协议（Metrics / Tracing）
| 维度 | 行业标准 | 注意点 |
|---|---|---|
| 指标 | Prometheus /metrics |
粒度过粗则无法区分单个上游故障 |
| 链路追踪 | OpenTelemetry / Zipkin | 代理是否透传 traceparent |
| 访问日志 | 自定义结构化 | ELK 或 Loki 集成友好度 |
10. 健康检查与主动探测
- 上游健康检查类型：TCP / HTTP / 自定义
- 被动健康检查（熔断器）的阈值与恢复策略
- 是否支持主动 passive 混合模式
- 健康检查配置是否可以路由级别差异化
四、安全与访问控制（3 项）
11. 鉴权与身份集成
- 是否支持 LDAP / OIDC / OAuth2 集成对接
- 正向代理场景的 NTLM / Kerberos 认证（Windows 域环境刚需）
- 基于 URL 路径 + HTTP 方法的精细 ACL
- IP 黑白名单（支持 CIDR）
12. 流量审计与内容过滤
- 是否支持 ICAP / WCCP 外接 DLP 或杀毒引擎
- URL 分类过滤（允许/拒绝/告警）
- MIME 类型拦截、文件大小限制
- HTTPS 解密（SSL Inspection）的吞吐代价与管理策略
13. 防滥用与速率限制
- 单客户端 / 单 IP / 单 API Key 的连接数与请求速率限流
- 是否支持分布式限流（需要 Redis 等外部存储）
- 突发流量是否允许 burst
- 限流触发后的响应行为：429 / 断开连接 / 排队
五、运维与部署（2 项）
14. 部署形态与高可用
- 部署方式：Docker / K8s / 裸金属 / VM
- 是否支持优雅关闭（graceful shutdown）与存量连接排空
- 与 Keepalived / kube-vip / DNS 轮询的 HA 配合成熟度
- 灰度发布：蓝绿 / 金丝雀部署是否可行
15. 升级与兼容性策略
- 大版本升级的迁移文档与 API 兼容性策略
- LTS 版本维护周期
- 回滚手段是否完整（配置、二进制、数据面分开）
评分模板建议
+-------------+-------+-------+---------+
| 评估维度 | 权重% | 得分 | 加权分 |
+-------------+-------+-------+---------+
| 协议兼容性 | 15 | /10 | |
| 性能与扩展 | 25 | /10 | |
| 可观测性 | 20 | /10 | |
| 安全管控 | 25 | /10 | |
| 运维部署 | 15 | /10 | |
+-------------+-------+-------+---------+
| 总分 | 100% | | /10 |
+-------------+-------+-------+---------+权重可根据自身场景调整。例如金融行业安全权重提到 40%，内部开发环境则更关注性能与可观测性。