1Panel AI网关Jev模式：多域名与模型智能路由实战

最近把 1Panel 升级到最新版，顺手在应用商店里装了新上架的 AI 网关，更新日志里有一行很显眼：“新增支持 Jev 模式”。我第一反应是：这不就是把反向代理、虚拟主机和模型路由揉到一起了？但真正上手配置之后，发现这里面的门道比想象中多。如果你也在被一堆模型 Key、多个域名、多个应用同时调用 AI 接口搞得头大，这篇文章值得花十分钟看完。我会从 Jev 模式的设计思路、和传统反向代理的区别、基于 1Panel 的完整配置步骤，到实操中踩过的坑，一次讲清楚。

1. AI 网关和 Jev 模式到底解决什么问题

1.1 从“一堆模型 Key”到“一个入口”

先说说我为什么需要 AI 网关。团队里同时接了好几家大模型服务，有的走 OpenAI 兼容协议，有的走各自原生 SDK，每个服务还有不同的 Key、不同的限额、不同的成本。客户端的代码想调用哪个模型就得改配置，改完还要重新发布。更麻烦的是，不同项目组各自拿着 Key 到处用，月底对账的时候根本分不清用量是哪个业务产生的。

AI 网关做的事情，说白了就是把所有模型服务藏在后面，对外只暴露一个固定入口。客户端不用再关心它调的是哪家模型，只要按照约定好的统一协议发请求就行。网关内部根据路由规则决定这个请求到底转给哪个上游。对我来说，它就像是一个“AI 请求的总线”，也是公司内部的“API 服务台”。

这次 1Panel 新增的 Jev 模式，则是在这个总线上加了一层“按域名分流”的能力。过去我们配置多个网站、多个域名，要嘛用虚拟主机区分，要嘛用 Nginx 反代到不同后端。现在 AI 网关也能用这套思路来管理模型，把每个域名当成一个虚拟站点，对应到不同的模型或模型组。听起来好像只是复用概念，但实际用起来的灵活性完全不一样。

1.2 Jev 模式与传统反向代理/虚拟主机的区别

很多人一听到“绑定多个域名”，第一反应就是 Nginx 的 server_name。1Panel 本身就支持给不同域名配置不同站点，或者做反向代理。那 Jev 模式跟这些有什么区别？我一开始也搞混了，后来对比发现，核心差异在“路由决策的维度”。

传统反向代理的规则很直白：来了一个请求，看 Host 头是谁，就转发到哪个后端地址。比如api.a.com转发到127.0.0.1:8000，api.b.com转发到127.0.0.1:9000。这个模型适合 Web 服务，但遇到 AI 请求就不太够用。

AI 请求除了要关心“从哪里来”（Host），还要关心“往哪里去”（目标模型）。同一个域名下，客户端可能既想调对话模型，又想调向量化模型。如果只用 Host 分流，就得给每个模型单独绑一个域名，域名数量会随着模型数量爆炸式增长。而 Jev 模式是在 Host 分流的基础上，再叠加了一层“模型维度”的路由判断。它可以根据请求体里的model参数、上下文长度、成本预算、甚至当前上游的健康状态，把同一个域名的流量再细分，转发到不同的模型服务上。

所以，Jev 模式更像是“虚拟主机 + 智能路由”的合体。它先把不同业务绑到不同域名，防止不同团队之间互相干扰；然后在同一个业务域内，又能够按照请求内容自动选择最合适的模型。这个设计解决了我最头疼的问题：不用给每个模型配一个域名，也不用在客户端写死模型名称，一切由网关说了算。

2. Jev 模式的核心设计拆解

2.1 路由维度：域名、模型、上下文长度、优先级

Jev 模式在 1Panel 的 AI 网关配置里，看起来是一个开关，但打开之后你会发现它其实是多维度路由规则的集合。我翻了一遍配置界面，把关键维度总结成了一张表：

这个表是我自己总结的，因为 Jev 模式的界面里并没有把所有维度都摆在一屏上。域名和模型名称是直接配置的，上下文大小、成本系数和优先级则需要在上游模型的基本资料里填。这里要提醒一点：不要一上来就把所有维度全部启用，我第一次用的时候把成本系数和优先级同时打开，结果流量分布完全看不懂。建议先从最基础的两条规则开始：按 Host 分流到不同上游，再按 model 分流到不同模型。跑通之后再慢慢加权重和成本控制。

2.2 智能路由的关键配置项与参数计算

既然叫“智能路由”，就不可能只是“如果 A 就转发到 B”这种固定逻辑。Jev 模式里真正智能的部分，一个是权重分配，一个是条件阈值。

权重分配很好理解。假设我配置了两个上游，一个用 GPT-4o，一个用某国产开源模型。我希望日常问答类请求 80% 走便宜模型，20% 走高级模型，做质量对比和兜底。那在 Jev 模式里就可以把两个上游的权重分别设为 80 和 20。网关收到请求后，会结合当前实例的负载情况做概率分发。这里有个容易忽略的点：权重不是单纯的随机数，它会考虑上游的当前并发数。如果便宜模型已经被打满了，新请求即使命中 80% 的权重，也会被自动转到高级模型，而不是硬塞过去超时。这个机制我是在日志里发现的，刚开始还以为配置错了，后来才明白是动态负载均衡在起作用。

条件阈值是个更细粒度的控制。比如我希望当请求的上下文长度超过 64k tokens 时，自动路由到支持 200k 上下文的模型。配置方式是在上游模型里设定“最大上下文长度”和“超限后的备用上游”。计算过程并不复杂：网关拿到请求后，会预估输入 tokens 和输出上限，然后相加，如果这个值超过当前模型的阈值，就改投备用上游。我在实测中故意用长文测试，发现切换的延迟增加大概 200 毫秒，主要是多了一次模型筛选的 JSON 解析。这个代价完全可接受。

参数配置还有一个容易踩的坑：max_tokens并不能代表完整的上下文占用。有些客户端会把历史消息都传给模型，导致输入 tokens 远比你想象得大。Jev 模式默认只读取请求体里的messages数组做估算，如果你用的是二进制流或特殊协议，最好在网关里打开“请求体缓存”选项，否则路由判断会丢数据。我的处理方式是在网关前面再套一层轻量代理，把请求结构规范化，Jev 模式的命中率一下子提升了好多。

2.3 上游健康检查与故障转移

智能路由最重要的前提，是网关知道哪些上游是“活着”的。Jev 模式默认会为每个上游配置一个健康检查地址。这个检查地址很有讲究。我第一次使用的时候，顺手填成了/v1/chat/completions，结果网关每隔几秒就发一条测试请求，不仅白白消耗了 tokens，还污染了对话日志。

正确的做法是：对于 OpenAI 兼容协议的上游，健康检查地址应该填/v1/models。这个接口只返回模型列表，不产生计费，而且响应很快。对于自建的推理服务，可以自己写一个轻量/health端点，返回 JSON 字符串{"status":"ok"}就行。

健康检查还有一个超时参数。AI 模型的响应本来就慢，尤其是推理模型，一次请求可能要十几秒。但健康检查是探活用的，不是正常推理，所以要单独设置一个比较短的超时，比如 3 秒。如果上游能在 3 秒内返回 200，就认为健康；如果连续失败 3 次，网关会把这个上游标记为不健康，后续请求全部转移到备用上游。我在实际配置中将间隔设为 10 秒，超时设为 3 秒，失败阈值设为 3 次。这样既不会频繁误判，又能在上游故障后 30 秒内完成切换。

故障转移的另一个隐藏机制是“会话亲和行为”。如果客户端开的是流式对话，中间断了再重连，网关需要把新请求路由到处理同一个会话的上游。Jev 模式默认会缓存最近 5 分钟的会话路由结果，但如果上游挂了，它会清除这个缓存并切换到备用上游，客户端需要重新发一遍上下文。这是设计上无法避免的，毕竟备用上游不可能有之前的会话状态。我一般建议关键业务在客户端做一次会话级别的重试，并提醒用户等待几秒。

3. 基于 1Panel 的完整配置实操

3.1 环境准备：升级 1Panel、安装 AI 网关应用

我用的环境是两台 4C8G 的云服务器，一台跑 1Panel 和 AI 网关，另一台跑自建的模型推理服务。1Panel 版本必须升到较新的版本，因为旧版的应用商店里没有 AI 网关入口。升级方式很简单，在面板右上角的系统设置里检查更新即可，升级不会动已有的网站和数据。

升级之后，打开左侧“应用商店”，在搜索框输入AI，会看到 AI 网关相关的应用卡片。点进去之后选择安装。安装过程其实就是通过 Docker 拉镜像、创建容器、挂载数据目录。1Panel 会自动分配端口，默认情况下网关会监听0.0.0.0:8118，但我建议后面把它绑定到 443，方便走 HTTPS。安装完成后，面板里会出现 AI 网关的快捷入口，第一次打开会要求创建管理员账号，这个账号不同于 1Panel 的面板账号，我建议分开设置，避免泄露。

这里有个小提示：AI 网关应用默认只会创建容器，不会自动创建数据库。如果后续配置比较多，建议在 1Panel 里单独创建一个 MySQL 或 SQLite 数据库给网关用。我选择的是 SQLite，因为单机场景不需要跨实例同步，而且备份起来简单，直接复制文件就行。如果你要做高可用，那必须用外部数据库，否则两个网关实例的数据会冲突。

3.2 配置虚拟主机：绑定多个域名到 AI 网关

配置多个域名和 AI 网关的结合点，在于 1Panel 的“网站”模块。你可以把 AI 网关看作一个后端服务，然后在 1Panel 里为它创建多个“反向代理”站点，每个站点对应一个域名。

进入“网站”菜单，点击“创建网站”，类型选择“反向代理”。在“代理地址”里填127.0.0.1:8118，也就是 AI 网关容器映射出来的地址。域名部分填你要绑定的第一个域名，比如ai.project-a.com。创建完成后，1Panel 会自动生成一份 Nginx 配置，并帮你申请 SSL 证书。我测试时发现，1Panel 默认会自动续签 Let's Encrypt 证书，这个功能非常省心，但前提是域名必须正确解析到这台服务器，而且 80 端口要能访问，否则证书申请会失败。

如果我有第二个域名，比如ai.project-b.com，就再创建一个反向代理站点，同样指向127.0.0.1:8118。这样两个不同的业务域名，都会把请求转发到同一个 AI 网关入口。到这里，已经实现了“一个网关入口，多个域名”，也就是 1Panel 的虚拟主机功能在 AI 网关上的体现。

但光做到这一步还不够。如果两个域名都指向同一个网关，那网关怎么区分请求来自哪个业务呢？答案是看 Host 头。AI 网关会读取请求的 Host，然后把它当作一个“业务标签”。在 Jev 模式下，这个标签会跟模型路由规则绑定。所以配置好反向代理之后，不要让客户端直接请求网关的 IP，而是要请求你绑定的域名，这样 Host 头才是正确的。

对于测试场景，你可以用 curl 模拟不同域名：

curl -k https://ai.project-a.com/v1/chat/completions \ -H "Content-Type: application/json" \ -H "Host: ai.project-a.com" \ -d '{"model": "gpt-4o", "messages": [{"role":"user","content":"hello"}]}'

如果你看到返回结果来自预期的上游模型，就说明域名绑定和路由都生效了。

3.3 配置 AI 网关上游模型与 Jev 路由规则

打开 AI 网关的管理界面，先进入“上游管理”。每一个上游代表一个真实的模型服务。点击“添加上游”，需要填写的信息包括：

• 名称：例如openai-compatible-main
• 协议类型：OpenAI Compatible、Anthropic Native 等
• Base URL：上游服务的实际地址，如https://api.example.com/v1
• API Key：上游服务的密钥
• 模型列表：该上游支持哪些模型，多个用逗号分隔
• 健康检查路径：推荐填/v1/models
• 超时时间、并发数、权重

填完之后，最好先点“测试连接”，1Panel 会直接调用一次健康检查接口，确认 Key 和地址都没问题。

接着进入“路由管理”，这里就是 Jev 模式的配置区域。首先把开关从“兼容模式”切换到“Jev 模式”。然后配置如下：

{ "rule_name": "project-a-default", "match_host": ["ai.project-a.com"], "match_models": ["gpt-4o", "gpt-4o-mini"], "upstream": "openai-compatible-main", "weight": 100, "fallback_upstream": "backup-model-service" }

这段 JSON 的作用是：当请求的 Host 是ai.project-a.com，且请求体里的 model 是gpt-4o或gpt-4o-mini时，转发到openai-compatible-main。如果这个上游不健康，则转发到backup-model-service。

如果我希望同一个域名下的其他模型走另一个上游，就再配置一个规则，匹配顺序从上往下，命中第一条就停止。这个行为其实很像防火墙规则，所以在配置规则的顺序时要注意。我把精确模型名的规则放在最前面，把通配符规则放在最后面，避免误命中。

Jev 模式里还有一个让人惊喜的配置项：“隐藏真实模型名”。开启后，网关会把上游模型的名称映射成一个内部模型名。客户端即使拿到了路由日志，也不知道背后实际调用的是哪家模型。这对生产环境非常有价值，尤其是当你不想让第三方商业公司知道你用了多少量的时候。

3.4 Jev 模式下的反向代理多网站场景

有人会问：既然 AI 网关已经能绑定多个域名了，那 1Panel 里原本的“反向代理多个网站”功能还需要用吗？我反而觉得，这两个功能配合起来才是完整方案。

比如我有个自建的 RAG 知识库，它跑在另一台服务器上，通过 8000 端口提供服务。这个知识库也需要调用 AI 模型。这时候我可以做两层反向代理。第一层，在 1Panel 里创建一个反向代理站点，把rag.project-a.com转发到知识库服务器的 IP 和端口。第二层，在 AI 网关中把rag.project-a.com这个 Host 识别为一个业务标签，并且给它单独分配一个模型池。这样，知识库和普通的对话应用虽然都挂了同一个 AI 网关，但走的模型路由完全不同。知识库请求会被优先分配到大上下文模型，而对话应用则走低成本模型。

这种组合方式特别适合“多个网站共用同一个 AI 网关”的场景。以前我可能需要为每个网站单独部署一套模型代理，现在只需要让各网站的反向代理指向同一个网关 IP 就能做到精细分流。1Panel 的“网站”管理界面里也能清楚看到每个域名对应的反代配置，出问题时就能快速地定位是代理层的问题还是网关层的问题。

当然，这里有个前提：不要把所有域名的代理地址都填成 AI 网关的 8118 端口，除非你希望域名对应的服务真的是 AI 接口。如果有些网站只是普通 Web 服务，它们应该继续指向各自的 Web 应用端口，只有 AI 相关的业务才指向网关。我看到有些朋友图省事，把所有网站都反向代理到网关，然后靠网关去判断 Host 是不是 AI 请求，结果普通网站的请求也会被转发到模型上游，造成 400 错误。务必区分清楚。

4. 实战中遇到的常见问题与排查技巧

4.1 域名证书与端口占用

1Panel 在创建反向代理站点时，会自动为域名申请 SSL 证书。但很多人在多域名场景下会遇到“证书申请失败”的提示，最常见的原因是域名没有解析到当前服务器。我开始也遇到了一次，检查发现原来ai.project-b.com的 DNS 解析记录被误写成了另一个 IP。解决方法很简单：到 DNS 服务商把 A 记录改成正确的 IP，然后在 1Panel 里点击“申请证书”重试即可。

另外，反向代理站点默认会占用 80 和 443 端口。如果服务器上还跑着其他 Web 服务，比如 Nginx 面板或 Docker 容器，也要监听 443，那么 1Panel 创建站点时就会报“端口被占用”。我的处理方式是：只保留 1Panel 自带的 Nginx 处理 80/443，其他 Docker 容器一律不用宿主端口，而是连接到 1Panel 创建的 bridge 网络，通过容器名互相访问。这样既安全又避免端口冲突。

多域名共用一个网关时，SSL 证书是按域名单独签发的，所以每个域名都要有自己的证书。1Panel 支持通配符证书，比如*.project-a.com，如果你有多个子域名，一次性申请通配符证书会更方便。但通配符证书一般用 DNS 验证，需要去 DNS 服务商配置 TXT 记录，这个操作没法全自动，除非你把 DNS 服务商的 API 配置到 1Panel 的“证书管理”里。我目前只用了单域名证书，因为我的域名数量不算太多，维护成本可以接受。

4.2 路由规则不生效或走了默认出口

Jev 模式设置完之后，最常见的问题是：明明匹配了ai.project-a.com的 Host，请求却打到了默认上游。排查这个问题，我先看网关日志。打开 AI 网关的“运行日志”，观察每一条请求的路由结果。如果日志显示match_host: false，那大概率是请求的 Host 头不对。

一种情况是客户端用了 IP 直接访问，没有带 Host。另一种情况是反向代理设置时把 Host 头覆盖了。1Panel 在创建反向代理时，默认会传透 Host 头，但如果手动修改过 Nginx 配置把proxy_set_header Host $proxy_host改掉了，那么后台收到的 Host 就是上游地址而不是域名。解决办法是把该行改回proxy_set_header Host $host;并重载 Nginx。

还有一种情况：请求的 model 不在任何规则里。Jev 模式在匹配不到具体模型时，会走一个名为 “default” 的隐式路由。这个隐式路由默认是禁止转发的，会直接返回 404。所以如果你的客户端传了一个规则里没有覆盖的模型，就会看到 404。我建议在路由配置里加一条“匹配所有模型”的兜底规则，指向一个稳定的上游，避免因为拼写错误导致线上故障。

4.3 健康检查误判与上游响应超时

健康检查是智能路由的基石，但它也是问题多发区。我遇到过上游服务明明正常，但 1Panel 的 AI 网关却一直显示“不健康”的情况。查看日志发现，网关每次请求/v1/models时都超时，原因是上游服务把这个接口也走了鉴权中间件，一旦 Key 过期，就会跳转到登录页，返回的不是 JSON 而是 HTML。健康检查做的是状态码校验，只要返回 200 就算健康，而 200 的 HTML 页显然不代表模型可用。

正确的做法是启用健康检查的“响应内容校验”。在 Jev 模式的上游配置里，可以填写一个期望的响应内容，比如"data"，网关会检查响应体里是否包含这个字符串，只有包含才认为健康。我建议填gpt-4o或者你的默认模型名称，这样能确保/v1/models确实返回了模型列表，而不是某个登录页面。

上游响应超时的问题更隐蔽。AI 模型的响应时间波动很大，普通聊天可能在 1 秒内返回，但长文本写作或推理模型可能耗时 20 秒。我一开始把全局超时设成了 10 秒，结果稍微复杂一点的请求全都被网关强制中断，客户端收到 504。后来我把“推理类模型”单独建了一个上游分组，并把超时时间设成 60 秒；而普通对话分组保持 15 秒。这样既不会让普通请求等太久，也不会误杀长任务。

4.4 日志分析和调试方法

最后分享几个我最常用的调试方法，几乎能解决 90% 的疑难杂症。

首先，看请求日志时，重点关注route_key字段。它能显示出请求命中了哪条规则。我通常这样过滤：

tail -f /opt/1panel/apps/ai-gateway/*.log | grep route_key

如果发现命中规则不是预期的那条，就回看配置里规则的排列顺序。规则是自上而下匹配的，一旦第一条命中了就不会继续往下走，所以要把最具体的规则放在最上面。

其次，用 curl 排除干扰。当有疑问时，直接绕开 1Panel 的反向代理，用网关的内网地址测试：

curl http://127.0.0.1:8118/v1/chat/completions \ -H "Content-Type: application/json" \ -H "Host: ai.project-a.com" \ -d '{"model": "gpt-4o", "messages": [{"role":"user","content":"test"}]}'

如果这个请求能正确路由，问题大概率出在 Nginx 层。如果请求能返回结果，但日志显示命中了错误规则，那就检查请求体的 model 字段是否有隐藏字符。我曾经遇到客户端传的 model 前后多了空格，导致精确匹配失败，最后走了兜底规则。这个问题用日志里的原始 JSON 一抓就出来了。

还有一个调试技巧：直接在后端上游服务上抓请求。在 Jev 模式下，网关转发请求时会保留原始请求的 Body，并在 Header 里加一个X-Upstream-Route字段，标注它来自哪条路由规则。你可以让后端服务记录这个 Header，方便核对请求是否真的正确到达。尤其是在多级反向代理的场景下，这个 Header 是定位链路的最佳标记。

最后说一下我对 Jev 模式的整体感受。它并没有发明什么玄奥的新技术，而是把虚拟宿主机的思路和 AI 网关的路由能力很好地结合在了一起。对于已经深度使用 1Panel 的用户来说，学习成本非常低，因为你不需要再学一套复杂的 API 网关配置语法，只要懂域名、懂 Nginx、懂一点模型参数，就能把一套多业务共用的 AI 网关跑起来。我个人在实际操作中体会最深的一点是，先稳定再智能：先把域名和模型的基础路由配好，再逐步叠加权重、成本和故障转移。如果你一上来就想做“全自动最优路由”，大概率会像我第一次一样，看着一堆规则互相打架，反而连最基本的请求都发不出去。先把 Jev 模式当成一个更聪明的反向代理来用，等跑通了，再慢慢解锁后面的高级能力，这才是最稳的上手姿势。