Spring Security 默认将未认证请求统一映射为 401，当应用抛出 500 等业务异常时，若 /error 端点未被显式放行，Spring Boot 的错误处理机制会被 Security 拦截并返回 401，掩盖真实错误状态。
spring security 默认将未认证请求统一映射为 401，当应用抛出 500 等业务异常时，若 `/error` 端点未被显式放行，spring boot 的错误处理机制会被 security 拦截并返回 401，掩盖真实错误状态。
在 Spring Boot 3.x（配合 Spring Security 6+）中，一个常见却极易被忽视的问题是：任何未预期的服务器端异常（如数据库表不存在、空指针、SQL 语法错误等）均被响应为 401 Unauthorized，而非应有的 500 Internal Server Error。这并非业务逻辑缺陷，而是 Security 配置与 Spring Boot 默认错误处理机制冲突所致。
根本原因：/error 端点被 Security 拦截
Spring Boot 内置的 BasicErrorController（或自定义错误控制器）通过 /error 路径统一处理所有未捕获异常，并根据 ErrorAttributes 渲染 JSON 或 HTML 响应。但在你的 SecurityFilterChain 中：
.authorizeHttpRequests()
.requestMatchers("/api/v1/auth/**", "/api/v1/docs/**").permitAll()
.anyRequest().authenticated() // ← 此处隐含：/error 也需认证！
由于 /error 未被列入 permitAll() 白名单，当控制器抛出异常后，请求会重定向至 /error —— 而该路径因未认证，触发 AuthenticationEntryPoint，最终返回 401，完全掩盖了原始异常（如 PSQLException: relation "core.clientss" does not exist）。
正确修复：显式放行 /error 端点
只需在 requestMatchers 中添加 /error（注意路径匹配规则）：
@Bean
public SecurityFilterChain securityFilterChain(HttpSecurity http) throws Exception {
http
.cors().and().csrf().disable()
.authorizeHttpRequests(authz -> authz
.requestMatchers(
"/api/v1/auth/**",
"/api/v1/docs/**",
"/error" // ✅ 关键修复：允许未认证访问错误处理器
).permitAll()
.anyRequest().authenticated()
)
.sessionManagement(session -> session
.sessionCreationPolicy(SessionCreationPolicy.STATELESS)
)
.exceptionHandling(exception -> exception
.authenticationEntryPoint(authenticationEntryPoint)
)
.authenticationProvider(authenticationProvider)
.addFilterBefore(jwtAuthFilter, UsernamePasswordAuthenticationFilter.class)
.logout(logout -> logout
.logoutUrl("/api/v1/auth/logout")
.addLogoutHandler(logoutHandler)
.logoutSuccessHandler((req, res, auth) -> SecurityContextHolder.clearContext())
);
return http.build();
}
⚠️ 注意事项：
- 路径必须严格匹配：Spring Boot 默认错误路径为 /error（非 /actuator/error 或其他变体）；
- 若使用自定义 ErrorController 映射到其他路径（如 /api/error），则需同步放行该路径；
- 不要移除 .authenticationEntryPoint(...) —— 它仅对认证失败场景生效，不影响正常错误流程；
- 此修复不影响 JWT 认证逻辑，仅确保错误传播链不被 Security 中断。
验证效果
修复后，原示例中的 PostgreSQL 表名错误将正确返回：
HTTP/1.1 500 Internal Server Error
Content-Type: application/json
{
"timestamp": "2023-05-15T17:36:26.670+00:00",
"status": 500,
"error": "Internal Server Error",
"trace": "...",
"message": "JDBC exception executing SQL [select ...]; nested exception is org.postgresql.util.PSQLException: ERROR: relation \"core.clientss\" does not exist"
}
而非误导性的 401 Unauthorized。
进阶建议：增强错误可观测性
为避免敏感信息泄露，生产环境推荐配置全局异常处理器，统一格式化错误响应：
@RestControllerAdvice
public class GlobalExceptionHandler {
@ExceptionHandler(Exception.class)
public ResponseEntity<errorresponse> handleGenericException(Exception ex, WebRequest request) {
log.error("Unhandled exception for request {}", request.getDescription(false), ex);
return ResponseEntity.status(HttpStatus.INTERNAL_SERVER_ERROR)
.body(new ErrorResponse("Unexpected error occurred"));
}
// 可单独捕获 DataAccessException、ValidationException 等细化处理
}</errorresponse>
同时，在 application.yml 中关闭开发模式下的详细堆栈（server.error.include-stacktrace: never），兼顾安全性与调试效率。
至此，你已从根本上解决“所有异常都返回 401”的陷阱——这是 Spring Security 6+ 与 Spring Boot 3.x 错误处理协作的典型边界问题，明确放行 /error 是标准且必要的实践。
