Shiro 跨域报错的核心原因在于过滤器链的执行顺序冲突，当浏览器的同源策略发起跨域请求时，会先发送一个 OPTIONS 预检请求以验证服务器是否允许该跨域行为，由于 Apache Shiro 的安全过滤器通常配置在过滤器链的前端，它会优先拦截这个 OPTIONS 请求进行权限校验，因为 OPTIONS 请求不携带 Shiro 认证所需的 Session 或 Token，Shiro 会判定其为未授权访问并直接拦截，导致请求无法到达后端的 CORS 处理逻辑，浏览器收到的不是允许跨域的响应头，而是 401 或 302 重定向，从而在控制台抛出跨域异常，解决此问题的根本原则是确保 CORS 过滤器的执行顺序优先于 Shiro 过滤器，或者在 Shiro 配置中显式放行 OPTIONS 请求。
深入解析 Shiro 跨域报错的根本原因
在 Java Web 开发中，特别是前后端分离架构下，跨域资源共享（CORS）是必须面对的问题，Shiro 作为一个强大且灵活的安全框架，其核心职责是保护应用资源，这导致它与 CORS 的默认行为存在天然的冲突，要彻底解决这一问题，首先需要理解 HTTP 协议中的“预检机制”。
浏览器在发起复杂的跨域请求（如带有自定义 Header 的请求或非 GET/POST 请求）之前，会自动发送一个 HTTP 方法为 OPTIONS 的“预检请求”，这个请求的目的仅仅是询问服务器：当前的源、方法和头部是否被允许，服务器需要响应特定的头部，如 AccessControlAllowOrigin 和 AccessControlAllowHeaders。
如果项目中使用了 Shiro，Shiro 的 ShiroFilter 往往被配置为拦截所有请求，当 OPTIONS 请求到达时，Shiro 会尝试获取当前用户的 Subject，由于预检请求通常不携带 Cookie（即 withCredentials 为 false）或携带的 SessionID 在服务端未对应任何活跃会话，Shiro 会认为这是一个未认证的请求，根据 Shiro 的默认配置，它会抛出 AuthenticationException 或重定向到登录页面，请求链路中断，负责添加 CORS 响应头的过滤器（如 Spring 的 CorsFilter）根本没有机会执行，浏览器收到的是 401 Unauthorized 或 302 Found，而非预期的 200 OK 和 CORS 头部，进而报出跨域错误。
浏览器预检机制与 Shiro 认证流程的冲突
这种冲突本质上是一个“鸡生蛋，蛋生鸡”的问题，浏览器需要先通过 OPTIONS 请求确认权限才能发送真实数据，而 Shiro 需要先解析请求头甚至 Session 才能确认权限，在传统的单体应用或同源应用中，这不是问题，但在前后端分离场景下，前端部署在 http://localhost:8080，后端部署在 http://localhost:9090，这种冲突就会暴露无遗。
具体表现为：前端发起请求 > 浏览器拦截并发送 OPTIONS > 服务器端 Shiro 拦截 > Shiro 发现未登录 > Shiro 拒绝访问或重定向 > 浏览器收到非 200 响应且无 CORS 头 > 浏览器控制台报错 CORS policy: No 'AccessControlAllowOrigin' header is present on the requested resource，开发者往往误以为是 CORS 配置缺失，实际上是因为安全网关把 CORS 配置的执行机会给“杀”掉了。
专业解决方案一：调整过滤器链执行顺序（核心方案）
最权威且推荐的解决方案是调整过滤器链的执行顺序,确保处理 CORS 的过滤器在 Shiro 过滤器之前执行，在 Spring Boot 集成 Shiro 的场景下，可以通过 FilterRegistrationBean 来精确控制过滤器的优先级。
Spring 容器中的 Filter 加载顺序可以通过 @Order 注解或 setOrder 方法控制，数字越小，优先级越高，越先执行，我们需要将 CORS 过滤器的 Order 值设置得比 Shiro 过滤器的 Order 值更小。
如果你使用的是 Spring Web MVC 自带的 CorsFilter 或者是第三方库如 ShiroCors 提供的过滤器，应该在配置类中显式注册：
@Bean
public FilterRegistrationBean<CorsFilter> corsFilter() {
FilterRegistrationBean<CorsFilter> registrationBean = new FilterRegistrationBean<>();
registrationBean.setFilter(new CorsFilter(corsConfigurationSource()));
// 设置优先级，数值越小优先级越高，必须小于 ShiroFilter 的优先级
registrationBean.setOrder(100);
return registrationBean;
} 通过这种方式,当请求到达时，CORS 过滤器会率先处理 OPTIONS 请求，直接返回 200 状态码和必要的允许跨域头部信息，Shiro 过滤器随后执行，但它只处理实际的业务请求（如 GET、POST），而不会干扰 OPTIONS 预检，这种方法不仅解决了报错，还符合安全逻辑：跨域校验属于传输层协议，应当先于应用层的安全认证。
专业解决方案二：在 Shiro 配置中显式放行 OPTIONS 请求
如果无法修改全局过滤器链的顺序,或者项目结构较为复杂，另一种行之有效的方案是在 Shiro 的配置中，明确告诉 Shiro 放行所有的 OPTIONS 请求，这相当于在 Shiro 的安检口设立一个“VIP 通道”，专门用于预检请求。
在 Shiro 的 ShiroFilterFactoryBean 配置中，通常有一个 filterChainDefinitionMap 用于定义 URL 拦截规则，我们需要添加一条规则，匹配所有路径的 OPTIONS 请求，并将其设为 anon（匿名访问，即不需要认证）。
Map<String, String> filterChainDefinitionMap = new LinkedHashMap<>();
// 放行 OPTIONS 请求，key 是路径匹配，value 是过滤器名称
filterChainDefinitionMap.put("/**", "anon"); // 仅用于演示，实际生产需更精确
// 或者更精确的匹配
filterChainDefinitionMap.put("/api/**", "corsAnon"); 标准的 Shiro 默认过滤器中没有专门针对 HTTP 方法的过滤器，为了实现这一点，通常需要自定义一个过滤器，继承 PathMatchingFilter 或 AccessControlFilter，在 isAccessAllowed 方法中，判断当前请求的 HTTP 方法是否为 OPTIONS，如果是，直接返回 true（允许通过），不再进行后续的认证检查。
这种方法的优点是不依赖容器的过滤器加载顺序,完全在 Shiro 体系内解决问题，但缺点是需要编写额外的代码或引入自定义过滤器，增加了维护成本。
专业解决方案三：利用 Nginx 反向代理处理跨域
在微服务或高并发生产环境中,通常会在应用服务器前部署 Nginx 作为反向代理，从架构设计的角度来看，将跨域处理交给 Nginx 是最高效的方案，这不仅能减轻 Java 容器的压力，还能统一管理所有服务的跨域策略。
在 Nginx 的配置文件中，针对特定的 Location，添加 CORS 响应头：
location / {
# 处理 OPTIONS 预检请求
if ($request_method = 'OPTIONS') {
add_header 'AccessControlAllowOrigin' '*' always;
add_header 'AccessControlAllowMethods' 'GET, POST, OPTIONS, PUT, DELETE';
add_header 'AccessControlAllowHeaders' 'DNT,XMxReqToken,KeepAlive,UserAgent,XRequestedWith,IfModifiedSince,CacheControl,ContentType,Authorization';
add_header 'AccessControlMaxAge' 1728000;
add_header 'ContentType' 'text/plain; charset=utf8';
add_header 'ContentLength' 0;
return 204;
}
# 处理实际请求
add_header 'AccessControlAllowOrigin' '*' always;
proxy_pass http://backend_server;
} 配置中的 always 参数至关重要，它确保即使后端应用（如 Shiro）返回了 401 或 404 错误，Nginx 依然会强制追加跨域响应头，这样，无论后端 Shiro 如何拦截，浏览器都能收到合规的 CORS 头，从而避免控制台报错，这是解决 Shiro 跨域问题最彻底、最具有架构前瞻性的方案。
独立见解与最佳实践建议
在处理 Shiro 跨域问题时，许多开发者容易陷入一个误区：试图在 Controller 层使用 @CrossOrigin 注解解决问题，这通常是无效的，原因在于，请求在到达 DispatcherServlet 分发到 Controller 之前，就已经在 Filter 链层被 Shiro 拦截并终止了，Controller 层的注解根本无法执行，解决方案必须在 Filter 层或 Web 服务器层实现。
关于安全性,不建议在生产环境中将 AccessControlAllowOrigin 设置为通配符 ，特别是当请求需要携带凭证（Cookies）时，最佳实践是动态配置允许的源列表，或者在 Nginx 中根据请求头 Origin 进行变量匹配，确保只有受信任的前端域名可以跨域访问。
解决 Shiro 跨域报错不仅仅是代码层面的修补，更是对 Web 请求处理生命周期的一次梳理，优先推荐使用 Nginx 反向代理方案，其次是调整 Spring Boot 过滤器链顺序，最后才是修改 Shiro 内部配置，遵循这一优先级，能够确保系统在安全稳定的前提下，优雅地解决跨域难题。
相关问答
Q1：为什么我在 Controller 上加了 @CrossOrigin 注解，依然报错 Shiro 跨域？A1： 这是因为 Shiro 的过滤器执行顺序早于 Spring MVC 的 DispatcherServlet，当请求到达时，Shiro 会先进行权限校验，如果校验失败（如 OPTIONS 请求未携带 Session），Shiro 会直接向浏览器响应错误或重定向，请求根本不会转发到对应的 Controller 方法，@CrossOrigin 注解失效，必须将 CORS 处理逻辑前置到 Filter 层或 Web 服务器层。
Q2：在 Shiro 中放行 OPTIONS 请求是否会带来安全风险？A2： 不会，OPTIONS 请求本身只是浏览器的“预检”机制，用于查询服务器支持的 HTTP 方法和头部，它并不携带实际的业务数据，也不会修改服务器状态，放行 OPTIONS 请求仅仅是允许浏览器完成协议握手，真正的业务请求（如 GET、POST）依然会经过 Shiro 的严格权限验证，这是符合 HTTP 标准且安全的做法。
您在配置 Shiro 跨域时还遇到过哪些棘手的问题？欢迎在评论区分享您的解决经验，我们一起探讨。
