企业官网建设流程全解析

1Panel的AI网关最近更新了一个让我很感兴趣的特性：智能路由新增了Jev模式。之前做多模型统一接入的时候，我基本靠权重轮询硬撑，要么把一个高价模型打到冒烟，要么把低价模型压到超时。换到Jev模式之后，网关会根据上游节点的实时表现动态分账，谁健康、谁便宜、谁稳定，流量就偏向谁。这篇文章不聊那些一搜就能查到的功能简介，直接说我对Jev模式的理解、在1Panel里怎么配、真实使用时遇到过哪些坑，以及怎么顺手解决多域名绑定和虚拟主机这类周边需求。

1. Jev模式到底是什么：先搞懂它和普通路由的本质区别

1.1 从“写死上游”到“让网关自己决定”

1Panel的AI网关，本质上就是一个带智能转发能力的反向代理。说得直白一点，你原来手动配置Nginx反向代理，把/v1/chat/completions请求转发到某个固定的API地址，AI网关做的事情也是转发，只不过它不是“写死”一个目标，而是按照路由策略，在一组上游服务里挑一个来接收请求。

在Jev模式出现之前，1Panel里主要用的还是传统方案：要么手动指定某个上游，要么用权重轮询。手动指定适合服务商没换、模型没调整的情况，但一旦上游挂掉，请求就直接失败。权重轮询解决了“多个上游分担流量”的问题，却解决不了一个更现实的问题：不同AI模型的延迟、价格、限额、稳定性完全不一样。拿同一个轮询把请求均匀分给一个高价模型和一个低价模型，低价模型被高负载打满，高价模型也在处理大量简单请求，成本和可用性两头都没顾好。

Jev模式的出现，就是为了让网关不再“盲转”，而是根据每个上游节点的实时状态做判断。这里的思路和平时用外卖软件的评分机制有点像：不是单看哪家价格最低，也不是单看哪家送得最快，而是综合评分、准时率、历史差评，再加一点“短时间表现”的动态权重。网关帮你在多个模型服务之间做选择，选出的结果更贴近真实需求。

1.2 Jev模式的“即时评估”逻辑

关于“Jev”这个命名，官方资料说得不算多，社区里有人解释为Jitter Evaluation，也就是“抖动评估”。我实际用下来，觉得这个说法比较贴切。它的核心逻辑是：在一个评估周期内，网关会收集每个上游节点最近一段时间的响应延迟、错误率、健康状态、可用性、单价等数据，然后算出一个综合得分，再根据得分动态调整流量分配。

整个过程不是一次性的静态权重，而是持续滚动的评估。比如某个上游前五分钟很稳，但最近三十秒内连续出现超时，那么它的得分就会被拉低，流量占比也会跟着降下来。如果它恢复了，得分又会慢慢涨回去。这种机制对AI场景特别有意义，因为LLM服务的响应时间不像普通网页那样稳定，同样的模型在不同时段、不同并发下，延迟可能差好几倍，单看平均延迟根本反映不了真实可用性。

Jev模式在计算得分时，通常绕不开这几个维度：上游健康检查结果、最近窗口的平均响应时间、错误率、抖动程度、还有成本相关的设定。你可以把健康检查和错误率看成一道安全线，一旦触线直接降权；延迟和抖动是日常评分的核心；而成本则是一个调整因子，让网关在“快”和“便宜”之间找到一个适合自己的平衡点。

1.3 三种路由策略横向对比

这张表对比下来，结论其实很清晰：如果你只是把同一个模型API部署在多台机器上做普通负载均衡，权重轮询完全够用；但如果你要在一个网关后面接不同厂商的模型，或者把自建推理服务和商业API混在一起，那么Jev模式的动态评分就重要得多了。

2. 在1Panel里启用Jev模式：完整配置步骤

2.1 准备工作：你至少需要这些东西

开始配置之前，先把需要的条件准备好。第一，一台已经装好1Panel的服务器，版本尽量用最新的社区版，因为AI网关相关的功能和界面在持续迭代，旧版本不一定有Jev模式的选项。第二，至少两个上游AI服务地址，可以是OpenAI兼容接口、自建vLLM服务、或者其他大模型API服务商。第三，准备好API Key和对应的模型名称。

另外要注意，AI网关一般建议配合域名使用。本地测试当然可以用IP，但实际对外提供服务时，最好提前把域名解析到服务器，并且在1Panel里配置好HTTPS证书。如果你后面打算用1Panel实现虚拟主机功能，绑定多个域名到不同的站点，这一步就更需要提前做好规划，别等网关建完了再改域名，那会给排查带来很多不必要的麻烦。

还有一点，别把上游API Key直接嵌在业务代码里。正确做法是在网关上配好统一鉴权，业务端只持有网关自己的访问凭证，上游的真实Key只存在于服务端配置中。这样即便业务端Key泄露，也不影响上游模型账户安全。

2.2 创建AI网关并添加上游节点

1Panel的AI网关入口，一般在“网站”模块里，不同版本可能在“应用”或“防火墙”附近有差异，但逻辑都一样：先创建网关实例，再配置上游节点，最后绑定对外访问的域名和路由策略。

具体操作步骤，可以按下面这个顺序来：

1. 登录1Panel，进入“网站”模块，选择“AI网关”，点击“创建”。
2. 填写对外访问域名，比如ai.example.com，端口按默认80/443即可。
3. 进入网关详情后，在“上游节点”里点击“添加上游节点”。
4. 每个节点填写名称、目标URL、协议类型。目标URL一般是https://api.modelprovider.com/v1这种完整地址，注意不要漏掉路径。
5. 在鉴权方式里选择Bearer Token或自定义Header，填入对应模型的API Key。
6. 配置健康检查路径，很多模型服务没有独立的/health接口，可以用/v1/models作为探测路径，能返回200就算健康。
7. 保存节点后，在“路由策略”中选择Jev模式。

这里有一个容易踩坑的地方：健康检查路径如果填错了，网关会认为上游一直不健康，Jev模式会把所有流量切走，导致请求全部报错。所以配置完节点后，先用浏览器或curl请求一下健康检查路径，确认返回的是200，再继续后面的步骤。

2.3 核心参数这样调才不踩坑

Jev模式不是选完就万事大吉，它还带了一批参数，理解这些参数才能真正把路由调顺手。我列几个实际使用中影响最大的参数，给你一个初始参考值：

先说评估周期。周期太短，比如1秒，网关会频繁切换流量，导致上游服务反复被连接和断开；周期太长，比如5分钟，故障发现就不够及时，用户体验会明显变差。15到30秒比较合适。采样窗口决定了“最近表现”统计的覆盖范围，5分钟能滤掉偶发波动，又不会让历史问题占太大权重。

节点最低权重这个参数要重点说。很多人在首次使用时，希望Jev模式能自动选择最优上游，就把最低权重设成了0，结果表现差的上游被完全剥掉流量，故障恢复后也没法自动回流。我建议设5%到10%，让每个节点都保留一点流量，便于灰度观察，也避免健康节点永远得不到验证。错误率熔断阈值则是一个安全阀门，超过阈值直接不参与路由，这比单纯降权更果断。

至于抖动惩罚系数，我实际测试下来的感受是：如果你希望用户体验优先，这个系数保持默认即可；如果你发现某些“慢但非错”的模型总被误伤，比如深度思考型模型响应时间天然长，那么可以适当调低惩罚系数，或者给这个上游单独开一个不启用Jev模式的网关。

2.4 绑定多个域名实现虚拟主机效果

1Panel实现虚拟主机功能并不复杂，本质上就是在面板里管理多个站点，每个站点绑定不同的域名。如果你是想让多个域名都访问同一个AI网关，最简单的做法是在同一个站点的“域名管理”里把这些域名全部绑定上去。这样不管用户通过ai.example.com访问，还是通过internal.example.net访问，最终都命中同一个网关，同一个路由策略。

但如果你想实现的是“不同域名走不同的上游服务”，那就不能指望通过一个网关的多域名绑定来完成。正确做法是，在1Panel里创建多个AI网关站点，每个站点绑定各自的域名，每个站点单独配置自己的Jev路由策略。对应到传统Nginx配置里，相当于为每个域名各写一个server块，而不是只改server_name。

这个区分在1Panel用户群里问得特别多。很多人以为“绑定多个域名”就是虚拟主机，其实虚拟主机的关键是“同机多站”，多域名只是入口。真正的多站隔离靠的是不同站点实例，不是靠一个站点里加了几个域名。如果你在同一个站点里绑了多个域名，然后想根据域名转发到不同上游，那就要在网关的请求匹配规则里做域名或路径判断，而不是开新的站点。这里建议先用表格想清楚：是“多域名一个网关”，还是“多域名多个网关”，再动手配置。

3. 一个真实场景：一套网关接管三个模型服务

3.1 场景描述：为什么需要智能路由

为了更直观地看Jev模式的效果，我把自己博客的AI助手接到了这套网关后面。上游大概分成三个服务：

服务A是某个商业大模型API，延迟低、稳定性最好，但价格按token算非常贵。服务B是国产开源模型的商业API，便宜很多，但偶尔会超时，尤其是高峰期。服务C是我自己用vLLM搭的推理服务，跑在一张消费级显卡上，成本几乎可以忽略，但受GPU负载影响，响应速度时快时慢，抖动比较大。

如果沿用权重轮询，问题马上就会暴露：服务A承担了它本不该承担的简单请求，服务B在高峰期被流量压垮，服务C则经常因为“卡顿”让用户看到超长loading。用Jev模式的动态能力，就是想让网关自己做判断：正常情况下多用服务B，便宜且速度也能接受；一旦B超时变多，就把请求切到A或C；C的负载不高时，也可以承担一部分流量。

3.2 配置落地：三个上游节点的参数设定

在1Panel的AI网关页面里，我添加了三个上游节点，初始权重设置成：A为10%，B为60%，C为30%。路由策略选择Jev模式后，把评估周期调成15秒，采样窗口保持5分钟，错误率熔断阈值设为15%，节点最低权重设为5%。

这里解释一下为什么初始权重要这样给。Jev模式并不是完全无视你设置的初始权重，它会以初始权重作为基准，再根据实时评分上下浮动。如果我把B设成60%，意味着正常情况下希望B再多接一点流量；如果B表现变差，它的比例会下降，但不会直接被清零，因为有5%的最低权重保底。A初始比例低，是因为贵，只有在B或C不可用时才上位。C的30%，配合动态评分已经够用。

上游节点都配置好之后，我额外在网关日志里开启了对后端响应时间的记录。这一步很多人忽略，但后面分析路由决策时特别重要，因为你不仅要看到流量最终到了哪个节点，还要知道网关当时的判断依据是什么。

3.3 验证Jev模式是否真的在工作

配置完成后，先用一个简单的请求验证连通性：

curl -X POST https://ai.example.com/v1/chat/completions \ -H "Content-Type: application/json" \ -H "Authorization: Bearer 你的网关Key" \ -d '{"model":"gpt-any","messages":[{"role":"user","content":"你好"}]}'

注意这里的model字段不用特别精确，因为启用Jev模式后，网关会按路由策略决定实际转发到哪个上游，model字段更多的是透传给上游做参考。如果返回正常，说明网关已经能通。

接下来做两个验证动作。第一个，在1Panel的网关监控页面观察请求数、平均延迟和错误率，看三个上游的流量分布是否符合预期。第二个，手动停掉服务B的API服务，模拟故障场景。正常情况下，Jev模式在一个评估周期内会发现B的健康检查失败或错误率上升，然后把流量切到A和C。我实测大概10秒后，B的接收请求数归零，服务A的请求比例从10%涨到35%左右，服务C从30%涨到60%上下。

这个效果已经能说明问题：它不是靠运气把请求转发到健康节点，而是有明确检测和切换逻辑。

3.4 运行观察与注意事项

持续跑了几天后，我发现Jev模式对“偶发超时”特别敏感。服务B本身错误率不算高，但只要有一次超过5秒的超时，它的得分就会立刻下降，流量权重也会跟着波动。这样做带来的好处是用户侧体感更好，因为请求都被优先交给了响应稳定的节点；坏处是，如果你的服务C是一次漫长的推理，比如输出几千字的文章，它天然响应慢，也很容易被降权。

对有这种场景的朋友，我的建议是：把长推理类型的模型单独建一个AI网关，关闭Jev模式或者把抖动惩罚系数调低，否则它会持续处于低权重状态，得不到充分使用。这次实际运行也让我意识到，Jev模式更像一个“动态调度器”，它默认把“稳定+便宜”作为参考目标，但每个业务的“划算”定义不一样，所以参数必须跟着场景调。

4. 常见问题与避坑指南

4.1 Jev模式不等于负载均衡

这是最容易误解的一点。传统负载均衡追求的是把请求均匀分发到所有节点，让每个节点承载差不多的压力。但Jev模式的目标不是均分，而是把流量引到综合得分最高的节点。也就是说，在长时间运行后，流量分布很可能一点不均匀，甚至大部分请求都会落在同一个上游上。这不是BUG，而是策略本身的设计。

所以，不要抱着“启用Jev模式就能让所有上游都忙起来”的想法。如果你想保留一定探测流量，确保某些节点始终在验证状态，就把节点最低权重调成5%或10%。如果只把某个节点当应急兜底，不希望它在正常时接收请求，那就把它当成冷备节点，权重设到最低。明确预期，就不会因为看到流量分布不均匀而紧张。

4.2 自动重试会把你的账单翻倍

在AI网关场景里，重试机制是一个隐藏陷阱。普通反向代理重试一次也就多花一点带宽，但AI请求重试，意味着同一个prompt被完整处理两次，按token计费的商业模型会直接扣两次费用。我在测试时遇到过这个情况：上游服务B因为超时返回错误，网关默认带重试逻辑，把请求又转发到了服务A，而服务A是高价模型。结果一次失败请求产生了两次计费，账单直接多出一截。

如果你也遇到类似情况，建议在网关配置里把“自动重试”关闭，或者只保留“连接超时重试”，不要对读取超时和5xx错误做重试。AI请求的幂等机制并不总是生效，重试带来的收益往往小于成本风险。另外，有条件的话，可以在请求Header里带上一个请求ID，方便在网关日志里排查是否发生了重复发送。

4.3 多域名绑定与独立路由别搞混

越来越多的朋友用1Panel实现虚拟主机功能，把多个域名绑定到同一台服务器上。在AI网关上，最常见的问题是我前面提过的：多个域名绑在同一个站点，却期望不同域名走不同上游。这里再强调一下，同站多域名只是别名，所有域名最终都命中同一个路由策略。

如果你想按域名区分上游，必须为每个域名单独创建AI网关站点，并在各自站点里绑定域名、配置独立的Jev策略。这样才符合虚拟主机的隔离语义。还有一个容易被忽视的点：多个域名如果都要走HTTPS，证书要分别绑定，或者是绑定一张覆盖多个域名的证书。在1Panel里用Let's Encrypt申请证书时，可以把多个域名放在同一个证书申请里，避免每加一个子域名就要重新申请一次。

4.4 故障排查速查表

这张表是我实际排查过程中经常翻的。绝大多数问题都出在健康检查路径、重试开关、以及对Jev评分机制的理解上，并不需要逐条看日志。

4.5 两个实用小技巧

最后分享两个我自己觉得节省排查时间的技巧。

第一个，给上游节点打上清晰可读的标签。比如“高优先级兜底”“默认便宜通道”“自建实验节点”这样直接在名称里体现用途，而不是只写一串API地址。Jev模式切换流量后，日志里能看到每个请求实际命中的节点，标签清晰可以让你快速判断路由决策是否符合预期。

第二个，用好1Panel自带的日志记录。每次在网关页面看到异常流量分布时，别只盯着监控曲线的平均值，拉出最近一分钟的详细日志看具体响应码和延迟。Jev模式做的是即时评估，调试时重点看故障发生前后两个评估周期内的日志，基本就能复现路由变化的原因。

玩Jev模式这段时间，我最大的感受是它把“AI网关”从单纯的转发工具，变成了真正有决策能力的入口。但再智能的路由也需要有人理解它的脾气，把初始权重、评估周期、重试策略这些参数当成自己的业务需求去调，而不是一键开启就丢在后台不管。这个模式能不能成为1Panel AI网关的标配不好说，但至少对喜欢自己搭模型服务的玩家来说，它让“多模型接入”这件事终于有了一个顺手的入口。