tomcat 400 The valid characters are defined in RFC 7230 and RFC 3986
在遇到 Tomcat 因 URL 非法字符返回 400 Bad Request 时，选择在 Nginx 还是 Tomcat 中配置错误处理，需根据实际场景和需求权衡。以下是两种方案的详细对比及配置方法：
一、选择建议
| 方案 | 适用场景 | 优点 | 缺点 |
|---|---|---|---|
| Nginx 配置 | - 需要统一处理所有后端服务（如多个 Tomcat 实例）的 400 错误 - 静态错误页或简单 JSON 响应 | 性能高，统一性强，减少后端负载 | 无法处理动态内容（如根据错误详情返回不同信息） |
| Tomcat 配置 | - 需要动态生成错误响应（如 API 返回 JSON） - 错误处理逻辑与业务紧密相关 | 灵活性强，支持动态内容 | 配置分散，多实例需重复配置 |
推荐优先级：
- API 或动态响应场景 → 优先在 Tomcat 配置。
- 静态错误页或统一代理层处理 → 优先在 Nginx 配置。
- 混合场景 → 可同时配置，但需避免冲突（如 Nginx 覆盖 Tomcat 响应）。
二、Tomcat 配置方案（应用级错误处理）
1. 配置自定义错误页面
在应用的 WEB-INF/web.xml 中添加：