做微服务一年以上的团队基本都会遇到这个需求服务A用Feign调服务B的接口但B上挂了统一的认证授权逻辑导致A这套内部调用也被拦在半路。这个标题我实在熟因为我自己就在好几个项目里被“部分接口忽略认证”折腾过。它不是把Feign全局绕过安全认证而是要有一种可控、可审计、只对指定接口生效的放行机制。这篇文章我把自己试过的几种方案、踩过的坑、最后沉淀下来的推荐配置一次性讲清楚。适合正在搭微服务网关、或者维护服务间调用链路的同学参考。1. 场景拆解为什么需要“部分Feign接口忽略认证”1.1 三种典型的内部调用场景先说清楚一个前提。标题里写的是“部分Feign接口”而不是“所有Feign接口”。这一点很关键做安全和做业务的人对它的理解经常不一样。我接触过的项目里真正需要跳过认证授权的内部调用不外乎下面三类。第一类是配置与元数据拉取。服务启动的时候要从配置中心或者其他基础服务拉取环境配置、路由规则、资源列表。这个时间点非常尴尬业务token还没拿到服务实例本身的凭证也还在初始化如果目标接口强制要求认证启动流程直接卡死。我见过为了绕过启动问题有人把配置接口的认证临时注释掉结果忘记改回来线上漏了一个口子。第二类是异步回调通知。比如服务A处理完一个异步任务后需要回调服务B通知结果。这个动作是系统内部行为和某个登录用户没有直接关系。如果用发起请求的那个用户上下文去回调回调链路里用户的session可能已经过期了到时候反而报错。更合理的做法是把回调接口放行调用方通过内部凭证访问。第三类是健康检查与运维探活。服务注册中心、负载均衡器、容器编排平台都要定期探测实例的健康状态服务间互相也会探活。这些探测请求要是也走完整认证流程不仅浪费资源还容易在认证组件本身出问题的时候误报服务下线。这三类场景有个共同点调用方是“另一个服务”而不是“某个用户”。认证授权体系如果只考虑了“验证用户身份”没有区分“调用方是不是受信任的内部服务”就会出现误伤。理解了这一点再看后面的方案选型就更清晰了。1.2 一个看起来很省事的错误做法有些团队图省事直接在Security配置里把anyRequest().permitAll()打开或者把Feign涉及到的接口全部放行。这种操作我劝你千万别学。它带来的问题不是“安全性降低了一点”而是整个认证体系形同虚设。我印象很深的一个事故是在某个项目里因为健康检查接口一直401有人图省事把/actuator/**全部permitAll了。结果不只是health连env、heapdump这些敏感端点也一起暴露了出去。运维指标、内存快照、配置信息全部裸奔。后来安全测试一抓一个准差点出大问题。所以我对“部分接口跳过认证”这件事的第一条建议是放行范围一定要小而且最好肉眼一眼能盘点出来。路径前缀、白名单列表、注解标记都比全局放开可靠得多。后面讲的所有方案都是围绕“最小化放行”这个原则展开的。2. 方案选型从路径放行到请求头标记2.1 方案一SecurityFilterChain路径白名单最传统、也最普遍的做法是约定内部接口统一放到一个独立路径前缀下面比如/internal/**或/inner/**然后在Security配置里对这个前缀执行permitAll()。这个方案最大的优势是简单直接。配置只有几行安全审计的时候看路径就能理解哪些接口是内部接口哪些不是。而且代码层面不用额外引入任何复杂机制——Controller的RequestMapping直接加个前缀就好了。它的局限也同样来自“只靠路径区分内外”。如果网关层没有做好隔离外部请求的URL只要也写成/internal/xxx照样能打进来。也就是说路径白名单解决的是“认证授权要不要拦”的问题解决不了“谁有资格访问这个路径”的问题。所以它几乎总要配合网关路由把内部路径显式禁止外部转发。我在实际项目中一般会把前端可访问的所有接口放在/api/**下内部服务间调用放在/internal/**下网关只把/api/**暴露出去/internal/**一律拒绝外部流量。这样即使有人猜到内部路径也无法从公网触达。2.2 方案二Feign请求头标记配合服务端校验路径白名单能解决问题但很多团队会问一句怎么保证只有Feign调用能放行而不是所有打到这个路径的请求都放行这时候就需要“调用方标识”了。做法也很简单Feign客户端在发请求的时候自动加一个自定义Header比如X-Internal-Call: true再带上来源服务名X-Source-Service: service-a。服务端在SecurityFilterChain里虽然放行了/internal/**但业务代码或过滤器额外校验这个Header的值和来源如果不合法就直接拒绝。这个方案比纯路径放行更安全一点。外部普通用户不知道、也没有理由带这个Header网关在转发外部请求的时候也可以主动剔除自定义Header这样即使外部用户伪造了Header到了服务端也可能已经被剥掉。相当于多了一道防线。代价是要多写一个Feign拦截器和一段服务端校验逻辑。如果只有一两个接口需要这种保护可能显得有点重。但当内部接口多起来了这套机制反而能统一管理。2.3 方案三自定义注解标记内部接口再高级一点的玩法是自定义一个注解比如叫InternalApi然后打在Controller方法上。服务端通过拦截器判断当前请求对应的HandlerMethod是否带有这个注解带上了才放行。这个方案的好处是灵活不用强制约束路径前缀可以精确到方法级别。比如一个Controller里HTTP GET查询接口要求认证而某个内部回调接口不要求直接注解标一下就完事。但坏处也很明显拦截器里解析HandlerMethod需要注意代理问题方法上没标、类上标了继承逻辑要处理清楚而且运行时做注解判断多多少少会影响一点性能。对大多数场景来说前面两个方案已经够用注解方案反而容易写得复杂。我把这三个方案的对比整理在下面方便你根据团队情况直接选型。方案实现难度维护成本安全性适用场景路径白名单低低中大多数内部接口场景Header校验中中较高需要区分内外部调用自定义注解较高高高接口零散、精确控制3. 落地实操配置与代码示例3.1 Security配置类完整示例聊完选型直接上代码。下面这份配置是我在一个Spring Boot 2.7 Spring Cloud 2021.x项目里实际用过的写法你如果用的是Spring Boot 3.x包名从javax换成jakarta就行整体逻辑一致。Configuration EnableWebSecurity public class SecurityConfig { Bean public SecurityFilterChain filterChain(HttpSecurity http) throws Exception { http .csrf().disable() .sessionManagement().sessionCreationPolicy(SessionCreationPolicy.STATELESS) .and() .authorizeHttpRequests(auth - auth // 内部接口前缀统一放行 .requestMatchers(/internal/**).permitAll() // 健康检查也放行 .requestMatchers(/actuator/health, /actuator/info).permitAll() // 其余请求必须认证 .anyRequest().authenticated() ); return http.build(); } }这里有三个细节需要说明。第一csrf().disable()不是随便关的。无状态接口用token认证本身没有session维度的CSRF风险关闭是为了避免Feign调用时被CSRF拦截器挡下来。但如果你还有浏览器Cookie会话的场景这一步要再想想。第二/actuator/**只放行了health和info两个端点点不是整个端点组都暴露。这一点尤其重要env、heapdump这些端点最好单独控制要么不暴露要么加额外权限。第三如果你用的是Spring Security 6.xauthorizeHttpRequests里的requestMatchers已经是主流APIand()链式写法也变了。别拿旧版本的写法硬套否则配置不生效排查起来非常头痛。3.2 Feign侧自定义拦截器与Token透传服务端配置放行之后Feign这边分两种情况处理。第一种情况内部接口不需要用户上下文。这种情况下Feign根本不用转发用户的Authorization只需要加一个内部标识Header。我习惯写一个FeignInternalHeaderInterceptorComponent public class FeignInternalHeaderInterceptor implements RequestInterceptor { Override public void apply(RequestTemplate template) { template.header(X-Internal-Call, true); template.header(X-Source-Service, applicationName); } Value(${spring.application.name}) private String applicationName; }第二种情况部分内部接口需要知道当前用户是谁。比如服务A要代替用户去服务B查数据这时候可以把当前请求的Authorization头透传过去。实现方式是在拦截器里读取RequestContextHolder中的当前请求拿到token再放到Feign请求里Component public class FeignTokenRelayInterceptor implements RequestInterceptor { Override public void apply(RequestTemplate template) { ServletRequestAttributes attributes (ServletRequestAttributes) RequestContextHolder.getRequestAttributes(); if (attributes ! null) { HttpServletRequest request attributes.getRequest(); String authorization request.getHeader(Authorization); if (StringUtils.hasText(authorization)) { template.header(Authorization, authorization); } } } }这段代码看着简单实际用的时候有几个坑。一个是RequestContextHolder在异步线程里拿不到Request。如果Feign调用发生在Async方法、线程池任务或者消息监听器里attributes就是nulltoken透传就静默失效了。这种情况要么把token作为参数显式传进去要么用其他方式在异步链路里传递上下文。另一个是拦截器的Bean注册。不要自己在FeignClient里手写拦截器配置直接用一个Component的RequestInterceptor实现Spring Cloud OpenFeign会自动把它应用到所有FeignClient上。如果你同时注册了多个Interceptor它们的执行顺序也要留意。3.3 服务端Controller接口与内部路径设计服务端这边我建议Controller的路径设计和FeignClient的路径保持一致统一放在/internal前缀下。举例来说服务B要开放一个“根据订单号查询商品快照”的内部接口可以这样设计RestController RequestMapping(/internal/product) public class InternalProductController { GetMapping(/snapshot/{orderId}) public ProductSnapshot getSnapshot(PathVariable String orderId) { // 内部接口不需要当前登录用户上下文 return productService.getSnapshotByOrderId(orderId); } }FeignClient则这么定义FeignClient(name service-b, contextId internalProductClient) public interface InternalProductClient { GetMapping(/internal/product/snapshot/{orderId}) ProductSnapshot getSnapshot(PathVariable(orderId) String orderId); }有两个细节很容易忽略。第一个是contextId。当同一个服务里订了多个FeignClient指向同一个目标服务时如果不指定不同的contextIdSpring容器会因为Bean名字冲突启动失败。我见过不止一次有人踩这个坑临时抱佛脚给FeignClient加后缀才解决。第二个是路径拼接。FeignClient上的RequestMapping、方法上的GetMapping、以及FeignClient的path属性会拼接成最终URL。如果拼接出来不是/internal/product/snapshot/{orderId}服务端路径就完全对不上就算Security配置了放行请求也到不了Controller。所以排查“接口明明放行了还是401”之前先确认实际的请求URL是什么。服务端如果不想只依赖路径前缀也可以在过滤器中继续校验X-Internal-Call头。我通常写一个简单的OncePerRequestFilterComponent public class InternalAccessValidationFilter extends OncePerRequestFilter { Override protected void doFilterInternal(HttpServletRequest request, HttpServletResponse response, FilterChain filterChain) throws ServletException, IOException { String uri request.getRequestURI(); if (uri.startsWith(/internal/)) { String internalFlag request.getHeader(X-Internal-Call); if (!true.equals(internalFlag)) { response.setStatus(HttpStatus.FORBIDDEN.value()); return; } } filterChain.doFilter(request, response); } }这里如果你想更严格还可以校验X-Source-Service是不是预期的服务名。注意这个Filter要放在Security过滤器链之前或之后取决于你希望它在认证之前就先拦截还是在认证之后校验。我的做法是放在之前让越早拦截越安全。4. 常见坑与排查记录4.1 配置了permitAll但还是401先从这四步查这个问题出现的频率远超想象。明明Security配置里写了requestMatchers(/internal/**).permitAll()一调还是401。大多数人会怀疑Security配置没生效其实大部分原因出在别处。第一步确认是不是有多个SecurityFilterChain。如果你在同一个项目里既配置了自定义的JWT过滤器链又保留了默认的SecurityFilterChain请求可能先进了另外一条没放行的链。多个过滤链的执行顺序是严格按照顺序来的先匹配的链先处理不是“所有链都执行”。第二步检查自定义过滤器是不是已经在Security之前返回异常了。很多JWT过滤器在请求头没有token时会直接响应401。如果你的JwtAuthenticationFilter注册在很靠前的位置并且没有对/internal/**做跳过处理那请求根本走不到permitAll的决策逻辑。第三步确认Feign的实际请求URL。FeignClient的方法路径、类路径、path属性拼接可能和你预想的不一样。最简单的方式是临时在服务端加一个日志过滤器记录所有进来的URI一眼就能看到真实路径。第四步如果整个项目升级到了Spring Security 6.x检查配置API是否已经迁移。新版里WebSecurityConfigurerAdapter改了authorizeRequests改成authorizeHttpRequests路径匹配器也换了实现。配置没报错但行为不对多半是API用法还停留在旧版本。4.2 Feign请求头丢失服务端收不到自定义Header这个问题最诡异的地方在于本地单测的时候Header明明发过去了放到线上环境服务端就收不到。常见原因有三个。第一个是拦截器没有被Spring管理。有人把RequestInterceptor的实现在一个普通类里手动new出来自然会失效。一定要让它是容器管理的BeanSpring Cloud OpenFeign才会自动装配到请求链路里。第二个是线程池或异步场景下RequestContextHolder拿不到上下文。这个我在前面提过如果Feign调用发生在Hystrix信号量隔离、Sentinel线程池隔离、或者消息监听线程里父线程的RequestContext不会自动传过去。第三个是网关层把自定义Header剥掉了。很多网关会对请求头做白名单过滤只放行标准的Authorization、Content-Type这些。如果你想保留X-Internal-Call这类自定义Header需要在网关配置里显式放行。排查思路其实很简单先在服务端把当前请求的所有Header打出来确认服务端到底收到了什么。没有日志就去加日志别靠猜。4.3 Controller里取不到认证信息NPE来得猝不及防放行认证之后又一个新问题冒出来服务端Controller里如果用了AuthenticationPrincipal或者SecurityContextHolder.getContext().getAuthentication()拿到的可能是null。这个不是Security配置的问题而是被放行的请求本来就没经过认证自然不会有Authentication放进上下文。解决方式很直接内部接口尽量不要读取认证上下文里的用户信息。如果业务确实需要知道“当前是哪个用户发起的操作”把用户标识作为普通参数传过来。比如服务A从请求中解析出userId然后通过Feign参数传给服务B而不是指望服务B自己从token里解出来。这种设计还有个额外好处内部接口的入参明确方便做参数校验和审计记录。比“隐式依赖认证上下文”要规范得多。4.4 关于安全边界的几条建议放行不是裸奔有几条边界要守住。第一内部接口的路径和外部接口的路径必须可区分。/internal/**这套约定帮我避免过好多次误放行即使FeignClient写错了路径前缀还能兜底。第二网关层一定要拒绝外部访问内部路径。如果网关没有剥离自定义Header并且允许路由到/internal/**路径放行就会变成外部可访问的内部接口风险等级直接拉满。建议在网关侧显式配置内部路径不可从外部路由。第三所有内部接口放行都要有审计日志。至少记录来源服务、目标服务、路径、调用时间。出了安全问题至少知道是谁调的、什么时候调的。我自己的项目里会把这部分日志单独存一份不混在业务日志里。第四如果服务间调用安全要求特别高可以考虑用client_credentials模式给服务颁发独立凭证而不是简单放行。Feign在发起请求前先拿服务凭证再调用目标接口。这个方案更重但把“服务身份”这件事纳入了统一认证体系安全性和可追溯性都更好。普通项目先做前三条就够用。最后再分享一个我自己的习惯如果你去翻我参与过的项目会发现我几乎都采用了“路径前缀 Feign自定义Header 网关内网路径隔离”这套组合。路径前缀保证代码结构清晰自定义Header增加一道调用方校验网关负责隔绝外部流量。这套组合运行了好几个项目没有出过大问题排查也容易。另外一个小技巧内部接口的路径前缀我建议用/internal/而不是/inner/。因为“internal”这个单词在网关注册路由、安全策略、日志分析的时候都更语义化不容易和其他业务路径混淆。团队新人看一眼路径就知道这不是对外开放的接口思维负担会小很多。踩过这么多坑之后我最大的体会是Feign调用跳过认证本身不复杂复杂的是“部分跳过”的边界怎么划、怎么防、怎么审计。把边界想清楚了代码实现反而很快。如果一开始只想“先让它通了再说”后面大概率要花更多时间补安全漏洞。