Quarkus启用CORS后REST端点行为异常，原因何在？

1. 核对生产环境CORS配置细节 #

Quarkus的CORS配置在application.properties里，别让生产环境的配置和本地不一致：

• 确保quarkus.http.cors.origins精确指向Angular的域名，别用*——带认证的场景下，*和浏览器的凭证模式不兼容，会导致认证流程异常
• 确认quarkus.http.cors.methods包含GET,POST,PUT,OPTIONS，预检请求（OPTIONS）必须明确允许
• 检查quarkus.http.cors.headers是否包含Authorization,Content-Type这些必要头，同时quarkus.http.cors.credentials要设为true（基础认证需要浏览器带凭证）
• 排查是否因为profile切换（比如prod profile）导致配置被覆盖，本地的宽松配置没同步到生产

2. 排查预检请求（OPTIONS）的拦截问题 #

浏览器对PUT、带自定义头的POST这类非简单请求，会先发OPTIONS预检请求，这一步很容易出问题：

• 看受保护PUT端点的日志，有没有OPTIONS请求的记录——如果这个请求被认证过滤器直接拦截返回403，那后续的PUT请求根本不会触发认证流程，直接被浏览器拦截
• 必须确保OPTIONS请求不需要认证：要么在权限配置里加quarkus.http.auth.permission.public.paths=OPTIONS/*，要么在端点方法上给OPTIONS标记@PermitAll
• 对比浏览器和curl的请求：curl直接发PUT/POST不会触发OPTIONS，而浏览器会，这就是本地和生产、curl和浏览器行为差异的核心原因

3. 确认过滤器执行顺序 #

Quarkus里过滤器顺序错了，CORS头还没设置就先跑认证，浏览器拿到403后会因为CORS头缺失报错：

• 如果自定义了认证过滤器，检查@Priority注解的值——Quarkus默认CORS过滤器优先级是1000，认证相关过滤器优先级一般是2000左右，要保证CORS过滤器先执行
• 可以在过滤器里加日志，打印执行顺序，确认是先处理CORS还是先处理认证

4. 对比浏览器与curl的请求头差异 #

未受保护的POST端点用curl正常，浏览器返回403，大概率是请求头不一样：

• 用浏览器F12网络面板抓包，对比curl的请求头，重点看Content-Type、有没有额外自定义头
• 如果浏览器的POST请求带了application/json这类非简单头，会触发OPTIONS预检，要是这个OPTIONS请求被当成需要认证的请求返回403，浏览器就会拦截后续的POST请求
• 确认这个POST端点对应的OPTIONS请求是否被放开权限，有没有配置允许匿名访问

5. 排查生产环境反向代理的影响 #

本地没问题生产出问题，优先查反向代理（Nginx、网关等）：

• 检查代理是否正确转发Origin请求头，有没有私自添加或修改Access-Control-*响应头，导致Quarkus的CORS配置失效
• 确认代理是否允许OPTIONS请求通过，有没有把OPTIONS请求当成无效请求拦截
• 直接访问Quarkus应用的IP+端口（绕开代理）测试，如果问题消失，就是代理配置的锅

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