Retrofit+OkHttp3对接Spring偶发URL含分号被拦截问题求助

• 运营商透明代理流量劫持：移动网络场景下大量运营商会通过透明代理在请求URL后注入跟踪类矩阵参数（常见如;jsessionid=xxx、;cid=xxx），这类参数以分号开头，正好触发Spring StrictHttpFirewall的拦截规则。该场景完全匹配你提到的「移动网高发、WiFi低发、随机出现自动恢复、不覆盖所有用户」的特征，是概率最高的诱因。
• 动态参数编码异常：如果你的Retrofit接口使用了@Path(encoded = true)或者手动拼接URL，当路径参数/查询参数中存在未编码的分号时，会直接带入请求URL。弱网下多次重试时偶发编码逻辑失效也可能触发该问题。
• OkHttp低版本重试逻辑bug：你使用的OkHttp3.10属于较老版本，存在已知的重试时URL拼接异常的bug，多次重试的场景下可能意外引入分号字符。
• 自定义拦截器逻辑异常：如果存在未展示的自定义OkHttp拦截器（如埋点统计、参数注入类拦截器），偶发逻辑错误可能将带分号的内容拼入URL。

该问题与证书配置无关。如果证书校验失败，请求会在SSL握手阶段直接被客户端/中间节点拒绝，根本不会到达后端Spring服务层产生对应报错日志，你当前的证书钉配置未出现问题。

• 客户端补全全链路日志：在OkHttp拦截器队列的最外层新增请求日志埋点，记录所有异常请求的完整URL、请求头、参数内容，确认客户端实际发出的请求是否携带分号。注意不要只依赖现有BODY级别的日志，避免中间拦截器篡改URL后未被记录。
• 后端补全异常请求全量日志：在Spring防火墙拦截前新增过滤器，记录所有触发异常的请求的完整原始URL、来源IP、UA、请求头，定位分号出现的位置，确认是否为运营商注入的标准矩阵参数后缀。
• 复现场景抓包验证：针对可复现问题的用户，在移动网络环境下进行HTTPS明文抓包，对比客户端发出的请求与后端收到的请求内容，如果客户端发出的URL无分号但后端收到的有，可实锤为中间节点（运营商代理）篡改。
• 检查Retrofit接口定义：排查所有上传相关的接口，确认@Path注解是否设置了encoded = true，是否存在手动拼接URL的逻辑，路径/查询参数的编码逻辑是否存在漏洞。

• 后端最优修复：新增前置过滤器，在Spring防火墙执行前处理请求URL：检测到URL中存在分号时，直接截断分号及之后的矩阵参数内容，再将处理后的请求转发给后续业务链路。该方案不需要修改StrictHttpFirewall的安全规则，不会引入额外安全风险。
• 客户端规避方案：
  1. 升级OkHttp到3.12.x以上的长期支持版本，修复旧版本已知的URL处理、重试逻辑bug。
  2. 强制开启HTTP/2协议，运营商对HTTP/2请求的篡改难度远高于HTTP/1.1，可大幅降低代理劫持概率。
  3. 移除apiInterface()中每次置空Retrofit实例的逻辑，避免重复创建连接池产生的未知异常。
• 特殊场景兜底：如果确认是运营商注入的合法跟踪参数，可针对性配置Spring防火墙对指定路径的矩阵参数放行，不要全局开启setAllowSemicolon(true)。

内容的提问来源于stack exchange，提问作者user3398945