最近把服务器上的1Panel升到了新版收拾自己那堆AI服务的时候发现面板自带的AI网关模块里智能路由部分多了一个以前没见过的选项Jev模式。第一眼看到这个名字我真没看懂以为是某个冷门协议后来把文档翻了一遍又拿着真实请求跑了好几组测试才算摸清它的门道。它不像传统路由那样只看请求头里的model字段然后机械转发而是会去读请求体里的内容再决定把流量送到哪个上游供应商。这篇文章就聊聊Jev模式的用法以及我把它和反向代理、多站点部署结合起来之后踩到的一些坑。如果你是那种“手里有不止一家模型的API Key、有统一入口和成本控制需求、想把路由控制得更细一点”的人这篇内容应该能帮上忙。下面我会按背景、原理、实际操作、部署架构和踩坑的顺序一一展开。1. 为什么1Panel开始做AI网关从网站管理面板到API分发层1Panel这个项目刚出来的时候大家主要把它当成一个Linux服务器管理面板来用。它管网站、管数据库、管Docker容器界面做得比传统面板清爽配反向代理、配SSL证书、部署多个网站都很顺手。所以很长一段时间里社区里最常见的搜索词就是“1panel配置反向代理 多个网站”绝大多数人拿它解决的核心问题是如何在一台服务器上同时跑好几个 Web 服务。但这两年AI开发的需求起来之后情况有了明显变化。我自己在做一个企业内部AI助手时就遇到了一个很现实的问题同一个应用可能要同时接入好几家模型服务商。有的供应商便宜适合闲聊有的长上下文表现好适合处理文档有的视觉能力强适合分析图片还有一些敏感业务要求数据不出内网只能用本地模型。如果让应用代码直接去连这几家代码里就要到处散落API Key切换模型的时候还要改代码、改配置账单也是一团乱麻。1Panel的AI网关模块解决的就是这个入口问题。它把多家模型供应商统一接进面板对外只暴露一个兼容标准格式的API地址应用侧完全不用关心后面到底连了谁。调用方只需要拿一把网关颁发的Key请求进来之后由网关负责做鉴权、做转发、做计费记录。这个模式很像以前做微服务时统一的API网关只不过现在网关后面挂的不是微服务而是各种大模型服务。有了AI网关接下来自然就要面对路由问题。一个网关后面挂了三家供应商收到请求后到底转发给谁早期版本的做法比较简单通常是按请求里的model字段去匹配应用传“deepseek-chat”网关就转发给DeepSeek应用传“qwen-plus”网关就转发给通义。这种按模型名转发的规则在供应商少的时候够用但一旦业务复杂起来就会捉襟见肘。就拿我那个内部AI助手举例。项目里所有请求都统一使用一个模型名“chat-default”因为我不想让前端感知底层模型的变化。但不同请求的实际需求其实差异很大有的只是简单问答有的需要读图有的要写代码。按模型名路由在这种情况下几乎无能为力因为模型名一样目标供应商却有多种可能。这也是我后来为什么盯上Jev模式的原因——它把“智能路由”的判断维度从请求头扩展到了请求体终于可以按真实业务内容来做分发。对于一个已经管着好几个网站、几套反向代理的1Panel用户来说这其实是很自然的能力演进从管流量到管API再到管API背后的模型调度。2. Jev模式到底在智能路由里做了什么请求体会说话2.1 传统路由条件已经满足不了什么在Jev模式出现之前我理解的“智能路由”基本分成两条线一是按模型名查表命中哪个配置就转发给哪个供应商二是按调用方维度做分发比如不同的API Key对应不同的上游或者同一个Key内做简单的负载均衡。这两种方式都依赖请求的“外部标记”也就是说网关只关心你的请求头上写着什么不关心你的对话内容到底是什么。这种模式在几个典型场景里会很尴尬。第一统一模型名的场景就像我上面说的所有请求都叫“chat-default”根本没法区分谁是谁。第二内容差异极大的场景同一个模型名下面可能既有“帮我解释一下什么是量子纠缠”这种文本请求也有带着一张产品截图让模型分析的图片请求如果网关不能看到请求体就只能一刀切。第三敏感性差异比如某些prompt里带着公司内部代码片段这种情况理论上必须走本地模型但外部世界根本不知道请求体里装着什么传统路由自然无从判断。2.2 Jev模式的核心机制解析请求体再决策Jev模式的核心逻辑通俗讲就是“让网关打开信封看看信里写了什么再决定送到哪个邮局”。网关在收到/v1/chat/completions这类请求时不会急着转发而是先把JSON格式的请求体解析出来然后按管理员预置的规则去匹配关键字段最后才把请求转给命中的上游供应商。可配置的匹配点非常直接基本上请求体里的任何字段都可以作为路由依据。使用最多的是这几个messages里的文本内容判断用户问的是什么类型的问题messages里是否包含图片类型的消息块判断是否需要视觉模型messages里是否附带工具调用定义判断是否需要函数调用能力较强的模型请求体里是否开启了流式返回判断是否需要走对流式支持更稳定的上游自定义参数如果上游或网关额外扩展了字段也可以参与匹配。打个比方以前的路由是“门卫看工牌放行”工牌上写着哪个部门就去哪个楼层Jev模式相当于门卫还会拆开你的快递看一眼发现是生鲜就送去冷藏库是文件就送去档案室。虽然多了拆快递这个动作但对很多细分场景来说这一步必不可少。2.3 关于“Jev”这个名字的猜测关于Jev的全称我翻了不少地方也没找到官方解释。按功能表现来看我基本倾向于理解为“JSON Eval”的简称也就是对JSON请求体做求值判断。这个名字不算优雅但胜在直白它做的事情确实是评估JSON内容。哪怕后续官方给出的含义和我猜的不一样只要你知道它本质上是“按请求体内容做路由”用起来就不会跑偏。2.4 Jev模式在路由链路中的位置要说清楚Jev模式还得把它放在整个智能路由链路里看。我理解的路由流程是请求进来之后先做基础鉴权确认这把Key有没有调用权限然后进入路由决策阶段匹配规则并确定目标上游最后再做请求改写比如把外部暴露的model名映射成上游供应商真正识别的model名再完成转发。Jev模式主要作用于中间那段路由决策阶段。它可以独立成唯一的决策方式也可以和其他条件叠加使用。比如先判断调用方所属的团队再叠加Jev按请求体内容细分。这种灵活的叠加方式是我觉得它真正有价值的地方它不是要取代传统路由而是给路由决策补上了一个此前缺失的维度。3. 一次完整的Jev模式开通过程3.1 环境准备与上游接入我在正式配置之前先把1Panel升级到了支持AI网关模块的版本确认系统设置里能看到“AI网关”相关入口。如果你还没找到这个模块建议先检查面板版本AI网关应该是内置于较新版本里的功能不再需要单独装插件。然后就是接上游供应商。我这次配了两条线一条是DeepSeek用来处理日常文本推理另一条是我内网用Ollama起的本地模型专门处理那些不能出内网的请求。之所以选这两个作为测试组合是因为它们都能提供兼容标准格式的API接口接入方式非常接近配置起来最有代表性。在“模型服务”页面不同版本叫法可能略有差异有的叫“上游供应商”我把DeepSeek的接入信息填进去至少要有这几项配置项说明示例值供应商名称给这个上游起个容易认的名字DeepSeek主用API地址上游服务的Base URLhttps://api.deepseek.com/v1API Key上游服务商签发的密钥填自己申请的Key模型列表允许从网关转发到这个供应商的模型清单chat-default注意这里有个容易忽略的点网关暴露给你的应用层模型名和上游真正认识的模型名可以是两套东西。你可以让应用永远只调用“chat-default”网关在转发时再把这个名字改写成“deepseek-chat”或别的实际模型名。这个模型映射能力对Jev模式来说非常重要因为Jev负责的是“选哪条路”而模型映射负责的是“到了目的地之后亮出什么身份”两者配合好了前端才能稳定。Ollama的接入大同小异只是API地址填内网地址比如http://127.0.0.1:11434/v1。因为Ollama默认监听本地端口如果1Panel和Ollama在同一台服务器上这个地址最省事。3.2 配置两条核心Jev规则上游接好之后我进入智能路由模块把路由策略切到Jev模式然后开始添加规则。第一次配置时不要贪多先配两条一条是关键的“图片请求走视觉模型”另一条是“所有其他请求走默认文本模型”。规则参数大概是这样参数说明我的示例规则名称方便自己识别的名字图片请求优先走视觉模型链路方向配请求体还是响应体请求体字段路径定位要判断的数据位置$.messages[*].content匹配方式包含、等于、正则等存在匹配条件具体触发值type image_url目标上游命中后转发到谁Ollama视觉模型优先级数字越小越先生效10第一条规则的目的是拦截所有包含图片的请求。写过OpenAI兼容格式请求的人都知道消息体里如果是多模态内容content字段通常不是一个字符串而是一个数组数组里会有type字段来标识内容类型比如text表示文本、image_url表示图片。Jev规则要做的就是判断这个数组里是否存在type等于image_url的元素只要存在就说明这次请求不是纯文本应该转发给支持视觉的上游。如果你用的面板版本匹配语法比较严格可能需要写类似以下形式的表达式$.messages[*].content[?(.type image_url)]如果面板只提供简化的“包含/存在”匹配器也可以把字段指向content整体然后填一个image_url作为匹配关键字效果是一样的只是精度会稍差一些。第二条兜底规则更简单匹配条件直接设为“所有请求”目标上游指向DeepSeek优先级放100。这样只要前面的规则都没命中流量就会落到兜底上游保证前端永远有响应不会因为一条规则没匹配上就报错。3.3 用curl验证路由是否生效配置完规则我习惯先用最朴素的方式验证一遍而不是直接上业务代码。一是方便隔离问题二是能直观地看到网关返回的结果。先发一个纯文本请求确认它走默认上游curl -s http://127.0.0.1:18080/v1/chat/completions \ -H Content-Type: application/json \ -H Authorization: Bearer 你的网关Key \ -d { model: chat-default, messages: [ {role: user, content: 给我写一段Python冒泡排序} ] }再发一个包含图片块的请求确认它被Jev规则拦截并转到了视觉模型curl -s http://127.0.0.1:18080/v1/chat/completions \ -H Content-Type: application/json \ -H Authorization: Bearer 你的网关Key \ -d { model: chat-default, messages: [ {role: user, content: [ {type: text, text: 这张图里写了什么}, {type: image_url, image_url: {url: data:image/png;base64,这里是一长串base64内容}} ]} ] }两次请求的model字段都是“chat-default”但按预期它们的路由结果应该完全不一样。如果你打开了网关的调试日志或指标页面应该能看到这两次请求分别命中了哪条规则。我这边第一次请求命中的是兜底规则第二次图片请求命中了我配的高优先级规则。前端应用完全感知不到这种行为差异它只知道自己调了同一个接口地址、同一把Key、同一个模型名这就达到了我想要的统一入口加智能分流效果。4. 把Jev模式放进反向代理和多网站架构里4.1 为什么网关前面还要挂一层反向代理很多1Panel用户习惯把面板本身管理的那层反向代理看成“给网站用的”其实对AI网关这种后端服务它同样适用。我自己在实践里比较推荐的架构是外部流量先经过1Panel管理的Nginx反向代理再由反向代理转发到AI网关的端口最后由AI网关通过Jev规则分发给各个模型供应商。有人可能会问多绕一层是不是多余我的看法是这一层恰恰是必要的。首先反向代理帮你统一处理了HTTPS证书AI网关内部不需要再裸奔在公网上外部只能用80或443访问不能直接摸到网关端口。其次反向代理可以做域名和路径层面的分流让同一个网关实例同时服务多个业务线。再次Nginx层对请求体大小、超时时间、并发连接的控制逻辑已经很成熟没必要在网关里重新实现一遍。4.2 多个网站反向代理到同一个网关在1Panel里配置多个网站反向代理到同一个后端操作上并不复杂。网站管理页面里每创建一个网站就是一个站点可以选择“反向代理”类型然后把目标地址填成AI网关地址。我这边实际有两个业务入口一个是客服系统域名指向的时候走/api/ai-support/路径另一个是内部代码助手走/api/ai-code/路径。两者在1Panel里各建了一个站点后端都指向同一台服务器的AI网关端口区别只在于Nginx里的location前缀不同。这样在网关这一层就能根据原始URL路径区分请求来源。这段Nginx配置的关键是别把Host和X-Forwarded-Host丢掉location /api/ai-support/ { proxy_pass http://127.0.0.1:18080/; proxy_set_header Host $host; proxy_set_header X-Real-IP $remote_addr; proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for; proxy_set_header X-Forwarded-Host $host; } location /api/ai-code/ { proxy_pass http://127.0.0.1:18080/; proxy_set_header Host $host; proxy_set_header X-Real-IP $remote_addr; proxy_set_header X-Forwarded-Host $host; }在1Panel里这些内容可以在每个网站的配置文件编辑页面里调整。需要注意的是面板自动生成的upstream块不要乱动否则可能影响站点的其他功能。我一般只在server块内部加location保持反向代理逻辑独立。4.3 多站点入口与Jev规则的叠加这种多站点架构配合Jev模式之后灵活性会再上一个台阶。网关可以根据路径先做一个粗粒度的业务分组路径是/api/ai-support/的请求优先使用客服供应商组路径是/api/ai-code/的请求优先使用代码模型组。然后在每个组内部再用Jev规则做更细的内容级分流。举个例子客服系统里同样有用户上传图片咨询的情况如果路径级规则和内容级规则叠加实际决策逻辑就是先看路径知道这是客服业务再看请求体发现里面带了image_url最终转发给支持视觉的客服模型如果请求体里没有图片就转发给文本客服模型。这种多层级路由的好处是规则职责清晰路径分了业务请求体分了内容不会出现一条又长又难懂的全能规则。当然也有个前提就是每个业务组的供应商权限要配置清楚。不要让客服组的Key可以去调代码模型否则路由做得再细也管不住成本。我习惯在网关里针对每把Key配置可见的供应商范围这样Jev规则就算因为条件写错漏掉了某个请求也不会导致越权调用。5. 上线两周遇到的六个坑5.1 规则静默不命中问题出在匹配表达式上第一次配Jev规则之后我发了一组带图片的请求结果发现流量还是走到了默认上游日志里没有任何规则命中的记录。当时第一反应是功能坏了后来排查下来问题出在我写的匹配表达式少了一个层级。我要判断的content数组嵌套在messages下面实际结构是messages数组里每一项又有一个content字段而content本身可能是字符串也可能是数组。我最初写的表达式定位到的不是真正包含图片的那一段所以永远匹配不上。这个问题特别容易在“静默”状态下被忽略因为面板不会告诉你表达式写错了它只会安静地不命中。我的建议是规则上线之前一定要用真实的请求体结构去调试表达式别用脑内模拟。把一条curl请求里的JSON拿来逐层看确保每一层字段名都对得上。表达式里多一个星号、少一层索引结果差之千里。5.2 模型名映射缺失上游直接返回400Jev规则把请求路由到目标上游之后还剩下一个容易被忽略的动作请求里的model字段是否要改写成上游认识的模型名。因为我统一对外暴露的是“chat-default”但这个模型名既不叫DeepSeek的“deepseek-chat”也不是Ollama里真实的模型名如果网关不做好映射请求到达上游之后会被直接拒绝返回一个类似model not found的400错误。最早我只配了路由规则没配模型映射结果就是Jev成功把请求送到了正确的上游但上游不认这个名字整体链路还是失败的。解决方法是把该上游能接受的外部模型名和内部模型名做一一对应。比如“chat-default”对应DeepSeek时映射成“deepseek-chat”对应Ollama时映射成“qwen2.5-coder:latest”。数据上看起来只是多填了一把映射但少了这一步所有智能路由都是空谈。5.3 大图片请求体被Nginx拦在外面跑通基础流程之后我让前端同事开始联调。他那边一传带图片的请求就报413排查了半天才发现是Nginx默认的client_max_body_size太小默认通常只有1MB。一张产品截图转成base64之后动辄两三MB再加上文本和请求头很容易就超过限制。解决办法是在反向代理配置里放宽单条请求体的大小限制。我直接改到20MB对于产品截图场景已经足够。但也要注意不是无限放大越好过大的请求体会拖慢网关解析和上游推理的响应时间反而影响体验。建议按业务实际需求来定比如内部工具设个20MB以内就够用。5.4 超时重试导致同一请求被计费多次有一次我发现账单里某个上游的调用次数明显多于实际请求数检查之后发现是网关侧的超时重试机制在起作用。上游模型推理本身可能就需要十几秒甚至更长网关端的超时设得太短第一次请求还没等到响应就被判定超时网关自动向同一上游重发了一次最后用户看到两次回答或者一次回答加一次异常报错但计费已经按两次算了。这个问题不能简单归咎于网关上游推理时长本来波动就很大。我的处理方法是把超时时间放宽到合理范围同时关闭或降低自动重发次数宁可少一次重试也不要产生重复消费。如果需要保证请求可靠性可以在业务层做幂等而不是完全依赖网关重发。5.5 多个反代站点共用网关时Host头串线我同时挂了客服和代码助手两个站点反代到同一个网关一开始没注意Host头透传的问题结果发现Jev规则里基于来源路径做判断时经常把客服系统的请求识别成代码助手的来源。原因是最早的一份Nginx配置里两个location的proxy_set_header写得不一致某个header被覆盖成了默认值。这也算反向代理场景下比较隐蔽的坑。如果Jev规则没有使用请求来源路径只是纯粹按请求体内容判断这个问题可能一直不会被发现但如果你要按业务线做路径分流Host和X-Forwarded-Host就一定要配准确。我后来直接把两份配置拉平确保所有站点都显式设置相同的Header转发规则再手动发请求从两个入口各测了一轮确认Jev规则能拿到正确的来源。5.6 调试日志全开两天撑爆磁盘为了看路由命中情况我把网关的调试日志打开了几天结果日志文件膨胀得吓人。因为Jev模式会记录请求体的关键内容AI请求基本都带着完整prompt甚至可能带着图片信息的meta描述这些内容一旦全量落盘磁盘占用很快失控。后面我调整了日志策略正常流量只记录路由命中的规则ID、目标上游、耗时和状态码不记录prompt正文只有在排查具体问题时才临时开启包含请求体的详细日志并且排查完立刻关掉。磁盘空间无小事尤其是服务器本身还跑着面板和多个网站日志撑爆了会把整个环境拖垮。6. 性能和稳定性Jev模式不是银弹6.1 多出来的解析开销该怎么控制Jev模式既然要读请求体那就必然带来额外的CPU和内存消耗。一个几百字的小JSON请求还好说但如果上传大图和长文档网关在转发之前要把整个body完整解析一遍这个开销确实存在。更麻烦的是如果每条Jev规则都去跑一遍正则表达式高QPS状态下CPU很快会吃紧。我的实践经验是规则列表里把便宜的判断放在前面。所谓便宜判断就是ES里字符串查找这种轻量级操作正则表达式尽量少用尤其是放到高优先级位置的正则更要谨慎。另外网关内置的路由决策结果如果支持短时间缓存可以尽量用起来。比如10秒内相同模型名和相同规则特征的请求直接复用上一次的路由结果不必重新解析完整body。对于上游供应商切换不频繁的场景这个缓存时间放到30秒也是合理的。6.2 熔断、降级和监控缺一不可Jev模式会把流量按内容切分到多个上游这也意味着任何一个上游出问题影响面可能被放大。比如视觉模型上游突然不可用所有带图片的请求都会开始报错以前如果所有流量都走同一个上游出问题反而容易暴露现在规则一多故障面可能是局部的。我建议针对每个上游配置熔断阈值。当连续失败达到一定次数时网关应自动把这类请求切换到备用上游。比如视觉模型挂了可以把图片请求临时降级到文本模型虽然回答质量会下降但总比直接报错好。配合降级的时候注意模型映射要一起切换否则请求到了备用上游又会因为模型名不匹配而失败。监控方面我每天会看一眼各条Jev规则的命中统计。如果某条规则一次都没命中我不会觉得“流量还不够”而是会手动跑一条符合该规则的请求验证规则到底有没有写错。另外上游平均耗时和错误率的变化也要盯一下任何一条上游链路的异常都可能在Jev规则加持下被放大成局部业务故障。6.3 什么场景真的不需要Jev模式聊到这里也要说句公道话Jev模式不是越多越好的功能。如果你的环境只有一家模型供应商或者所有请求都可以固定转发到同一个目标那完全没必要引入它默认转发规则更简单也更省资源。另一种情况是虽然你有多个供应商但业务上只需要按模型名区分比如应用层已经严格约定好不同模型名对应不同供应商那传统路由也够用。Jev模式真正有价值的场景是请求体内容本身差异巨大且应用层无法或不想感知这些差异的时候。规则超过几十条之后维护成本会急剧上升与其把所有判断堆在一个网关里不如拆成多个网关实例不同业务团队各自管理反而更清晰。最后说点自己的体会我实际用下来的最大感受是Jev模式给AI网关补上了一个非常重要的“内容感知”能力它让你从“按名字转发”升级到“按内容决策”。但能力变强的同时责任也变重了——规则要设计得贴近真实业务表达式要经过实测模型映射要配齐日志监控和熔断降级也不能落后。尤其是在1Panel这种还能同时管理多个网站和反向代理的环境里只要把入口路径、Host透传、Jev规则层级想清楚就能搭出一套既能隔离业务线、又能按请求内容精细化调度的AI接入层。如果让我给刚开始接触Jev模式的用户一个建议我只会说一句先做一条图片分流规则跑通全程再慢慢叠加其他条件。规则宁少勿多先让链路跑通再考虑覆盖更多业务场景。这样排查问题的时候至少你还有一条清晰的“兜底路径”可以依赖。