核心问题是HTTPS重定向拦截了跨域预检OPTIONS请求，导致浏览器报ERR_INVALID_REDIRECT；应将CORS中间件置于HTTPS重定向之前，或在代理层统一处理以避免预检被重定向。
这个问题的核心在于：当浏览器发起跨域预检请求（OPTIONS）时，如果后端启用了 HTTP → HTTPS 的自动重定向（比如 ASP.NET Core 的 UseHttpsRedirection），而该重定向又作用于 OPTIONS 请求，就会触发浏览器的硬性限制——预检请求不允许被 3xx 重定向，直接报 ERR_INVALID_REDIRECT 或类似错误，导致后续实际请求根本不会发出。
确认是否是 HTTPS 重定向引发的预检失败
打开浏览器开发者工具 → Network 面板 → 筛选 OPTIONS 请求 → 查看响应状态码。如果看到 301 Moved Permanently 或 307 Temporary Redirect，且响应头中没有 Access-Control-Allow-Origin，基本可断定是重定向拦截了预检。
注意：即使目标接口本身支持 HTTPS，只要它对 HTTP 入口做了全局跳转，就可能误伤 OPTIONS 请求。
后端禁用预检路径的重定向（推荐）
不要让任何重定向逻辑介入 OPTIONS 请求。不同框架处理方式略有差异：
-
ASP.NET Core：在
Startup.cs或Program.cs中，把 HTTPS 重定向中间件放在 CORS 中间件之后，并确保UseHttpsRedirection()不作用于 OPTIONS：
app.UseCors(policy => policy
.AllowAnyOrigin()
.AllowAnyMethod()
.AllowAnyHeader());
// ✅ 把 UseHttpsRedirection 放在 UseCors 之后，且不拦截 OPTIONS
app.UseHttpsRedirection(); // 它默认不处理 OPTIONS，但需确认无自定义重定向逻辑干扰
-
Django：检查中间件顺序，确保
django.middleware.security.SecurityMiddleware（含SECURE_SSL_REDIRECT=True）不干预 OPTIONS；或在视图/中间件中对request.method == 'OPTIONS'提前返回 200。 -
Express / Node.js：在 CORS 中间件前加一层判断，对 OPTIONS 直接
res.sendStatus(204)，跳过后续所有中间件（包括重定向逻辑）。
前端避免触发预检（简化请求）
不是所有请求都会触发预检。若当前请求只是因为带了 Authorization、Content-Type: application/json 或自定义 header（如 x-request-id）才触发，可考虑临时降级为“简单请求”验证问题是否消失：
- 改用
Content-Type: text/plain或application/x-www-form-urlencoded - 暂时去掉自定义 header（如
x-request-id） - Token 改用 query 参数或 cookie（需后端配合支持）
⚠️ 注意：这只是排查手段，不能作为生产方案。真实业务中仍需支持标准鉴权头。
反向代理统一入口（生产环境首选）
让前端始终访问同源地址（如 https://your-app.com/api/...），由 Nginx / Cloudflare / 云网关将请求代理到真实后端，彻底规避浏览器跨域和重定向冲突：
- Nginx 配置中，
location /api/直接proxy_pass https://real-backend.com/ - 确保代理配置里显式返回 CORS 头（
add_header Access-Control-Allow-Origin "*"），且不启用内部重定向 - 关键点：代理层要能正确透传或响应 OPTIONS 请求，不把它转发给后端重定向逻辑
这种方式下，浏览器全程只跟一个域名通信，既无跨域，也无重定向干扰预检。
