Ocelot在.NET 6+中已基本弃用,官方推荐迁移到YARP;新建项目不应选用Ocelot,因其不支持原生minimal hosting、缺失gRPC透传、热重载能力弱且社区维护停滞。
Ocelot 在 .NET 6+ 中已基本弃用,新建项目请直接用 YARP;若必须维护旧 Ocelot 项目,核心问题是配置加载时机、中间件顺序和下游头透传逻辑,不是“怎么配”,而是“为什么配了没用”。
为什么 ocelot.json 配置总不生效
Ocelot 不是“读完 JSON 就跑”,它依赖
加载配置,而默认实现不监听文件变更、路径硬编码、且在
流程中极易被覆盖。
常见错误现象:
写对了但返回 404;
配了但
中间件完全没触发
根本原因:Ocelot 必须在
之后、
之前调用
,且不能和
混用
实操建议:改用内存配置(
),或跳过——YARP 的
原生支持
绑定和
热重载
.NET 6+ 中 JWT 验证为什么透传失败
Ocelot 本身不做鉴权,只做“转发器”。它把认证交给上游中间件,但需要严格对齐 key、顺序和头字段。
C知道
CSDN推出的一款AI技术问答工具
下载
必须在
之前注册,否则
找不到 provider
中的
必须和
的 name 参数完全一致(区分大小写)
Ocelot 默认不透传
到下游,
这类头需手动加进
或用自定义
补充;更简单的方式是下游直接读
,前提是 Ocelot 没改写
header
YARP 替代 Ocelot 的最小可运行配置
YARP 不需要独立配置文件,所有路由逻辑可写在 C# 里,也兼容
。关键是
和
对齐,且必须注册反向代理服务。
必须注册:
注意点:YARP 默认不转发原始
头,如需保留,得显式配置
并设
签名验证(如阿里云
)必须自己写中间件——Ocelot/YARP 都不内置该能力;典型坑是签名中间件提前消费了
流,导致下游读不到 body
真正难的不是写路由规则,而是理解“谁在什么时候读取请求流、谁在什么时候改写 header、谁在什么时候释放 connection”。这些细节在 Ocelot 文档里藏得深,在 YARP 里则要靠读中间件源码才能确认。别迷信配置项,先抓包看实际发出的请求长什么样。
IOcelotConfigurationProviderWebApplication.CreateBuilderDownstreamPathTemplateAuthenticationOptionsAuthorizationUseRouting()UseEndpoints()UseOcelot()MapControllers()AddSingleton() AddReverseProxy()IConfigurationChangeToken.OnChangeAddAuthentication().AddJwtBearer("Bearer", ...)AddOcelot()AuthenticationOptions.AuthenticationProviderKeyocelot.json"AuthenticationProviderKey": "Bearer"AddJwtBearer()ClaimsPrincipalX-User-IdGlobalConfigurationDelegatingHandlerHttpContext.UserAuthorizationappsettings.jsonRouteConfigClusterConfigbuilder.Services.AddReverseProxy().LoadFromConfig(builder.Configuration.GetSection("ReverseProxy"))HostForwarderOptionsPreserveHostHeader = trueX-SignatureRequest.Body