大体积 JWT Token 不会导致 TLS 层缓冲区溢出，但会引发 Apache/Nginx 等 Web 服务器 HTTP 解析层溢出；需在 Web 层设限（如 LimitRequestFieldSize）、应用层主动校验（Header 长度、URI 总长）、Token 设计精简（删冗余字段、不存敏感信息）、AJP 链路加固（禁用或调小 maxHttpHeaderSize）。
大体积 JWT Token 在 HTTPS 链路下本身不会导致 TLS 层缓冲区溢出，但会放大 Apache/Nginx 等前置 Web 服务器的请求解析风险——真正溢出发生在服务端 HTTP 解析层，而非加密传输过程。解决核心是“分层设限 + 提前拦截”，而非仅依赖 HTTPS。
Apache/Nginx 层：收紧请求边界
HTTPS 只保证传输加密，不改变请求结构。超长 Authorization Header（如含 Base64 编码的巨型 JWT）仍会触发 Web 服务器缓冲区限制失效或解析异常：
- LimitRequestLine 4096：限制完整 URI（含路径+查询参数）长度，防长路径拼接 Token
- LimitRequestFieldSize 2048：单个 Header（如 Authorization）最大字节数，直接截断超长 Token
- LimitRequestFields 100：防止攻击者发送数百个伪造 Authorization 头耗尽内存
- 启用 mod_security 规则：拦截 REQUEST_URI 或 Authorization 头长度 > 2048 的请求，返回 400
Java 应用层：校验与拒绝前置
不能依赖容器自动过滤，需在 Filter 或拦截器中主动控制：
- 读取 request.getRequestURL().toString() + "?" + request.getQueryString() 总长，超 4096 字节立即返回 414
- 遍历所有 Header：request.getHeader("Authorization") 若存在且长度 > 2048，直接拒收
- 校验必须基于原始字节流（ISO-8859-1 解码），避免 UTF-8 多字节导致长度误判
- 记录被拦截请求的 RemoteAddr、User-Agent、URI 前 128 字符，用于识别攻击模式
Token 设计侧：从源头压缩体积
再强的防护也不如合理设计。JWT 膨胀主因是 Payload 存了冗余字段或敏感信息：
- 移除非必要声明（如 iat、jti 若无审计需求可省略）
- 用户身份只存 sub（subject）和 role，不存完整用户对象或权限列表
- 敏感字段（手机号、邮箱）绝不放入 Payload；需时通过 sub 查库获取
- 改用 RS256 非对称签名，避免为兼容旧系统而降低密钥强度导致重复签发大 Token
AJP/Tomcat 连接链路加固
若 Apache 通过 AJP（mod_jk）连接 Tomcat，该协议默认头长度限制宽松（约 64KB），是常见溢出入口：
- 升级 Tomcat 至 9.0.31+ 或 10.0.2+，修复 CVE-2020-1938 相关缓冲区问题
- 禁用 AJP 协议，改用 HTTP/HTTPS 直连或使用 mod_proxy_http
- 在 Tomcat 的 server.xml 中显式配置：
maxHttpHeaderSize="8192"
