使用Spring Cloud LoadBalancer后Spring Security跳转与静态资源异常如何解决？

认证跳转失效原因 #

• 你当前的负载均衡仅通过WebClient转发了/和/port两个路径的请求，后端服务Spring Security触发未认证的302跳转时，WebClient默认不会将302响应透传给前端，而是自动跟随后端跳转请求，无法返回正确的登录页响应所以出现空内容。
• 后端服务返回的默认跳转地址指向自身端口（9091/9092），而非负载均衡的8080端口，就算透传跳转也会跳错地址。

静态资源丢失原因 #

• 负载均衡当前仅做了少量路径的转发，前端页面请求的CSS/JS等静态资源路径（如/css/xxx.css、/js/xxx.js）没有被转发到后端服务，8080端口本身不存在这些资源所以返回404。
• 你现在的实现仅做了指定接口的代理，不是完整的请求转发，所有路径的请求都需要被负载均衡转发到后端服务才能正常加载资源。

方案1：最小改动修复现有问题（无需迁移代码，适合短期测试/小项目） #

• 负载均衡侧改为全路径转发，不要只写死/和/port的映射，把所有/**的请求都按照路径转发到后端hariri服务集群，同时配置WebClient透传3xx跳转响应，关闭自动跟随跳转的逻辑。如果觉得自己写WebClient全路径转发太麻烦，可以把当前的负载均衡服务替换为Spring Cloud Gateway，只需要配置一条路由规则就能实现全请求转发，自动处理Cookie、重定向透传，不需要写额外代码。
• 后端A、B服务的Spring Security配置里，修改登录跳转的base地址为负载均衡的地址（http://你的负载均衡IP/域名:8080），保证跳转路径正确。
• 后端Thymeleaf配置修改静态资源引用为相对路径，不要写死服务端口，保证静态资源请求都发到8080端口，由负载均衡转发到对应后端服务。

方案2：标准微服务架构改造（适合长期维护的正式项目，推荐使用） #

• 将所有Thymeleaf页面、静态资源都迁移到负载均衡服务，负载均衡改为@Controller层处理视图跳转，负责页面渲染。
• 后端A、B服务移除Thymeleaf和页面相关配置，全部改为@RestController仅返回JSON数据，负载均衡需要数据时调用后端接口获取。
• Spring Security统一迁移到负载均衡层做全局认证，后端A、B服务仅做接口权限校验或者直接信任负载均衡的请求，不需要重复实现登录认证逻辑，彻底避免认证跳转不一致的问题。

如果是短期测试用，选方案1改动量小，半天即可修复所有问题；如果是正式项目长期维护，选方案2架构更清晰，后续扩容、排错成本低，避免多个后端服务重复实现相同的认证、页面渲染逻辑。

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