做微服务一年以上的团队，基本都会遇到这个需求：服务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.x，authorizeHttpRequests里的requestMatchers已经是主流API，and()链式写法也变了。别拿旧版本的写法硬套，否则配置不生效，排查起来非常头痛。
3.2 Feign侧：自定义拦截器与Token透传
服务端配置放行之后，Feign这边分两种情况处理。
第一种情况，内部接口不需要用户上下文。这种情况下Feign根本不用转发用户的Authorization，只需要加一个内部标识Header。我习惯写一个FeignInternalHeaderInterceptor：
@Component 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就是null，token透传就静默失效了。这种情况要么把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指向同一个目标服务时，如果不指定不同的contextId，Spring容器会因为Bean名字冲突启动失败。我见过不止一次有人踩这个坑，临时抱佛脚给FeignClient加后缀才解决。
第二个是路径拼接。FeignClient上的@RequestMapping、方法上的@GetMapping、以及@FeignClient的path属性会拼接成最终URL。如果拼接出来不是/internal/product/snapshot/{orderId}，服务端路径就完全对不上，就算Security配置了放行，请求也到不了Controller。所以排查“接口明明放行了还是401”之前，先确认实际的请求URL是什么。
服务端如果不想只依赖路径前缀，也可以在过滤器中继续校验X-Internal-Call头。我通常写一个简单的OncePerRequestFilter：
@Component 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出来，自然会失效。一定要让它是容器管理的Bean，Spring 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调用跳过认证本身不复杂，复杂的是“部分跳过”的边界怎么划、怎么防、怎么审计。把边界想清楚了，代码实现反而很快。如果一开始只想“先让它通了再说”，后面大概率要花更多时间补安全漏洞。
