移动端Spring Boot API调用失败，如何定位证书校验问题并修复？

本文共计1092个文字，预计阅读时间需要5分钟。

移动端 + AJAX/fetch 请求失败（status=0, responseText为空）通常并非代码逻辑问题，而是 HTTPS 证书域名不匹配导致的浏览器主动拦截请求。需通过 SSL Labs 等工具验证证书 subject alternative name（SAN）是否覆盖实际访问域名。

在您提供的代码中，移动端使用 XMLHttpRequest、桌面端使用 fetch，两者均指向同一 Spring Boot 后端接口 https://xxxxxxxxxx/api/v1/user/login，且在桌面端正常、移动端报 readyState = 4, status = 0 —— 这是典型的跨域或 TLS 层拦截信号，而非网络超时或服务不可达。关键线索在于：status = 0 在 XMLHttpRequest 规范中明确表示“请求未发出”，即浏览器在发起 HTTP 请求前已终止流程，常见于以下两类底层拦截：

✅ 核心原因：SSL/TLS 证书域名不匹配（Certificate Name Mismatch）
移动端浏览器（尤其是 iOS Safari 和 Android Chrome）对 HTTPS 证书校验更为严格。若您的 Spring Boot 应用部署在 AWS（如 EC2 或 ALB），所配置的 SSL 证书（例如由 Let’s Encrypt 或商业 CA 签发）的 Common Name (CN) 或 Subject Alternative Names (SANs) 中未精确包含前端实际访问的域名，浏览器将直接拒绝建立 TLS 连接，导致 XHR/fetch 返回 status = 0。
例如：

• 前端通过 https://m.example.com 访问页面；
• 后端 API 地址为 https://api.example.com；
• 但证书仅覆盖 example.com 和 www.example.com，缺少 api.example.com 或 m.example.com；
  → 移动端拒绝握手，请求被静默丢弃。

? 快速验证方法：

1. 访问 SSL Labs SSL Test；
2. 输入您 API 的完整域名（如 api.example.com）；
3. 查看 "Certification Paths" → "Subject Alternative Names" 是否完整包含当前调用域名；
4. 同时检查 "Handshake Simulation" 列表中 iOS / Android 主流浏览器是否显示 ❌（Failed）。

?️ 修复方案（三步落地）：

1. 更新证书 SAN 列表

   • 若使用 Let’s Encrypt：重新申请证书时添加所有必需域名

     certbot certonly --manual -d api.example.com -d m.example.com -d www.example.com

   • 若使用 AWS ACM：在控制台编辑证书，添加缺失的域名并重新部署至 ALB/API Gateway。

2. 后端 Spring Boot 强制 HTTPS（可选但推荐）
   在 application.yml 中启用重定向，避免 HTTP 混合内容风险：

   server: ssl: key-store: classpath:keystore.p12 key-store-password: changeit key-alias: tomcat forward-headers-strategy: native

3. 前端容错增强（辅助排查）
   在 onreadystatechange 中补充错误判断，区分真实失败与 TLS 拦截：

   newXHRRequest.onreadystatechange = function () { if (newXHRRequest.readyState === 4) { if (newXHRRequest.status === 0) { // 明确提示证书问题（仅开发/测试环境） document.getElementById('showError').innerText = '连接失败：请检查网站证书是否有效（可能域名不匹配）'; console.warn('XHR status 0 detected — likely TLS certificate mismatch'); } else if (newXHRRequest.status === 200) { const json = JSON.parse(newXHRRequest.responseText); localStorage.setItem("token", json.message); // 注意：原代码 data.message → json.message setTimeout(redirect1, 2000); } else { try { const json = JSON.parse(newXHRRequest.responseText); document.getElementById('showError').innerText = json.message || '登录失败'; } catch (e) { document.getElementById('showError').innerText = '服务器响应异常'; } } } };

⚠️ 重要注意事项：

• 不要依赖 e.preventDefault() / e.stopPropagation() 解决此问题——它们仅阻止表单默认提交，无法绕过 TLS 层拦截；
• jQuery 并不能规避证书校验，引入它只会增加包体积，无助于根本解决；
• 避免在生产环境使用 http:// 或自签名证书，移动端将彻底拒绝；
• 若使用 Cloudflare 等 CDN，请确认其 SSL 模式为 "Full (strict)" 并上传有效证书。

✅ 总结：移动端 status=0 是 TLS 握手失败的“指纹”，根源几乎总是证书域名配置缺陷。优先通过 SSL Labs 定位证书缺口，再更新部署，即可一劳永逸解决 AJAX/Fetch 在移动设备上的静默失败问题。