K3s 部署 NestJS LangChain 调用 LiteLLM 间歇性 404 问题排查一、问题背景最近部署了一个基于NestJS LangChain的 AI 后端服务后端运行在K3s集群中通过LiteLLM调用外部大模型服务。整体架构如下K3s Pod │ ▼ NestJS LangChain │ ▼ test.com │ ▼ 第二层 Nginx │ ▼ 第一层 Nginx │ ▼ LiteLLM │ ▼ vLLM │ ▼ 大模型最开始遇到的问题是 LangChain 偶尔报错404 status code (no body) Troubleshooting URL: https://docs.langchain.com/oss/javascript/langchain/errors/MODEL_NOT_FOUND/比较奇怪的是模型名称确认没有问题IP 配置确认没有问题LiteLLM 本身正常vLLM 本身正常NestJS 只有一个 Pod并发量非常低同一个请求有时候成功有时候 404宿主机调用正常K3s Pod 内调用偶尔出现 404因此一开始很容易怀疑 LangChain、模型配置或者 LiteLLM。最终发现问题并不在 LangChain也不在模型而是 DNS 多 IP 导致请求偶尔访问到了异常 IP。二、首先确认是不是 LangChain 的问题LangChain 报错404 status code (no body)因此第一步直接绕过 LangChain在 NestJS Pod 内使用 Node.js 原生请求测试 LiteLLM。请求POST /ai/chat/completions请求体{model:Reasoning,messages:[{role:user,content:hello}],stream:false}连续请求后发现200 200 404 200 404 404 200 ...这说明即使完全绕过 LangChain问题依然存在。因此可以初步排除LangChainLangChain Agent模型名称NestJS 业务逻辑三、确认 LiteLLM 是否正常继续测试GET /ai/models不带 API Key401 Authentication Error这反而是一个正常现象因为说明请求已经到达 LiteLLM。加入正确的 API Key 后200 OK说明K3s Pod ↓ Nginx ↓ LiteLLM这一条链路是正常的。四、测试域名本身继续测试curlhttps://test.com/可以正常访问。说明DNS 可以解析TCP 可以连接HTTPS 可以建立域名基本正常但是/ai/chat/completions仍然偶尔返回404因此问题开始缩小到不同请求可能没有到达完全相同的后端节点。五、检查 DNS在宿主机和 Pod 中分别执行getent hosts test.com发现域名实际上对应了3 个 IP 地址。例如test.com 192.168.0.25 192.168.0.26 192.168.0.27这里需要特别注意实际环境中的 IP 请以getent hosts返回结果为准。问题开始变得非常可疑。因为客户端 ↓ test.com ↓ IP1 / IP2 / IP3如果三个 IP 后面的服务配置不完全一致那么就可能出现请求 1 → IP1 → 200 请求 2 → IP2 → 404 请求 3 → IP1 → 200 请求 4 → IP3 → 404最终表现出来就是有时候成功 有时候失败六、排除 HTTP Keep-Alive由于请求表现为200 404 200 404一开始也怀疑 HTTP Keep-Alive 或 TCP 连接复用。因此测试时增加Connection: close强制每次请求关闭连接。测试多次之后仍然存在 404因此可以基本排除HTTP Keep-Alive / TCP 连接复用不是主要原因。七、确认 K3s Pod 到正常 IP 是否稳定经过进一步排查发现192.168.0.25这个 IP 是正常的。但是由于使用 HTTPS不能简单地curlhttps://192.168.0.25因为 HTTPS 会涉及SNIHostTLS 证书Nginx server_name如果直接通过 IP 访问可能出现TLS certificate mismatch或者 Nginx 没有匹配到正确的虚拟主机。八、使用正确的 Host SNI 测试使用 Node.js 测试时将目标 IP 设置为hostname:192.168.0.25同时设置servername:test.com并设置Host: test.com示例consthttpsrequire(https);constbodyJSON.stringify({model:Reasoning,messages:[{role:user,content:hello}],stream:false});constreqhttps.request({hostname:192.168.0.25,port:443,path:/ai/chat/completions,method:POST,servername:test.com,headers:{Host:test.com,Authorization:Bearer YOUR_API_KEY,Content-Type:application/json,Content-Length:Buffer.byteLength(body),Connection:close},rejectUnauthorized:false},res{letdata;res.on(data,chunk{datachunk;});res.on(end,(){console.log(res.statusCode,data);});});req.on(error,console.error);req.write(body);req.end();连续测试 20 次1 → 200 2 → 200 3 → 200 4 → 200 5 → 200 ... 20 → 200最终20/20 成功这一步非常关键。它说明K3s Pod 到 192.168.0.25 的网络链路是正常的。同时也证明Pod 到第二层 Nginx 正常HTTPS SNI 正常Host 正常/ai/chat/completions路径正常LiteLLM 正常vLLM 正常九、确认另外两个 IP继续对 DNS 返回的另外两个 IP 分别进行测试。注意必须使用和.25完全相同的测试方式只修改hostname例如IP1 192.168.0.25 IP2 xxx.xxx.xxx.xxx IP3 xxx.xxx.xxx.xxx测试结果192.168.0.25 → 正常 → 20/20 200 IP2 → 不通 IP3 → 不通这就基本确定DNS 中存在多个 IP但是只有其中一个 IP 能够正常提供当前 AI 服务。十、为什么会出现 404完整链路实际上变成了test.com │ ┌──────────────┼──────────────┐ │ │ │ ▼ ▼ ▼ 192.168.0.25 IP2 IP3 │ │ │ ▼ ▼ ▼ Nginx 异常节点 异常节点 │ ▼ LiteLLM │ ▼ vLLM当请求访问正常 IPPod ↓ 192.168.0.25 ↓ Nginx ↓ LiteLLM ↓ vLLM ↓ 200当请求访问异常 IPPod ↓ IP2 / IP3 ↓ 异常入口 ↓ 404 / 连接失败所以最终应用层看到的就是200 404 200 404 ...十一、为什么 LangChain 会报 MODEL_NOT_FOUNDLangChain 最终拿到的是HTTP/1.1 404LangChain 并不知道这个 404 是DNS 多 IPNginx 配置错误负载均衡异常Host/SNI 不匹配后端路由异常因此它只能根据 HTTP 状态码进行错误处理。最终出现404 status code (no body) MODEL_NOT_FOUND所以MODEL_NOT_FOUND并不一定代表模型真的不存在。本次案例中模型本身是正常的。成功请求已经返回{model:Reasoning,object:chat.completion}并且响应中可以看到 vLLM 指纹vllm-0.25.1-tp4-ep-123456798这进一步证明成功请求已经真正到达 vLLM。十二、为什么宿主机正常而 K3s Pod 异常这是本次问题比较容易误判的地方。宿主机测试正常并不能证明所有访问路径都正常。因为宿主机 ↓ DNS ↓ 可能一直访问正常 IP ↓ 200而K3s Pod ↓ DNS ↓ 多个 IP ↓ 可能访问到异常 IP ↓ 404因此宿主机正常 Pod 偶尔异常并不代表 LangChain 或 K3s CNI 有问题。必须进一步把 DNS 返回的多个 IP 分别测试。十三、最终解决方案由于另外两个 IP 不能删除但是当前 NestJS AI 服务只希望使用192.168.0.25因此可以让 K3s Pod 内部固定解析test.com到192.168.0.25而不是修改 NestJS / LangChain 代码。Kubernetes Deployment 可以使用hostAliases:配置apiVersion:apps/v1kind:Deploymentmetadata:name:your-backendspec:template:spec:hostAliases:-ip:192.168.0.25hostnames:-test.comcontainers:-name:backendimage:your-image这样 Pod 内部test.com ↓ 192.168.0.25而不会再随机访问其他 IP。十四、为什么不建议直接修改 NestJS 代码不建议直接把代码改成https://192.168.0.25/ai/chat/completions因为 HTTPS 不只是 IP 连接。还涉及SNI Host TLS Certificate Nginx server_name直接使用 IP 容易导致SSL certificate mismatch或者Nginx server_name 匹配错误更合理的方式是NestJS LangChain │ │ ▼ https://test.com/ai/... │ ▼ Kubernetes Pod 内部 hosts 固定解析 │ ▼ 192.168.0.25这样Host test.com SNI test.com仍然保持正确。十五、修改后验证修改 Deployment 后kubectl rollout restart deployment your-backend查看 Podkubectl get pods-owide进入 Podkubectlexec-ityour-backend-xxx --sh检查域名解析getent hosts test.com应该看到192.168.0.25 test.com然后测试 LiteLLMcurl-vk\https://test.com/ai/models\-HAuthorization: Bearer YOUR_API_KEY如果返回HTTP/1.1 200 OK再测试POST /ai/chat/completions连续请求几十次200 200 200 200 200 ...即可确认问题已经解决。十六、关于 CoreDNS 的说明这次排查过程中也容易怀疑 CoreDNS。需要明确CoreDNS 负责的是 DNS 解析而不是实际的 HTTP 数据转发。例如Pod ↓ CoreDNS ↓ test.com ↓ 192.168.0.25 192.168.0.26 192.168.0.27CoreDNS 的作用主要是告诉 Pod这个域名对应哪些 IP真正的 HTTPS 请求则是Pod ↓ 目标 IP ↓ Nginx ↓ LiteLLM因此如果192.168.0.25 → 200 IP2 → 不通 IP3 → 不通那么不能简单认为CoreDNS 有问题如果 DNS 返回的记录本身就是正确的那么 CoreDNS 可能完全没有问题。十七、这次问题的最终结论表面问题LangChain MODEL_NOT_FOUND实际问题DNS 多 IP ↓ 部分 IP 不可用 ↓ 请求偶尔访问异常 IP ↓ Nginx / 后端返回 404 或连接失败 ↓ LangChain 收到 HTTP 404 ↓ 报告 MODEL_NOT_FOUND最终通过 KuberneteshostAliases:-ip:192.168.0.25hostnames:-test.com让 K3s Pod 内的 NestJS 后端固定访问正常入口。十八、完整排查思路总结以后如果遇到LangChain 404 OpenAI API 404 LiteLLM 404 MODEL_NOT_FOUND 模型偶尔找不到不要第一时间认为模型不存在建议按照下面的顺序排查。1. 绕过 LangChain直接请求POST /chat/completions确认是不是 LangChain 自身的问题。2. 测试/models确认DNS ↓ Nginx ↓ LiteLLM是否正常。3. 检查 DNSgetent hosts your-domain.com确认是否存在多个 IP。4. 分别测试每一个 IPHTTPS 场景注意Host SNI TLS不能简单使用https://IP进行判断。5. 对比不同 IP例如IP1 → 200 IP2 → 404 IP3 → 不通那么重点检查DNS Nginx Ingress 负载均衡 反向代理而不是继续排查 LangChain。十九、最终经验这次问题最重要的经验是应用层看到的 404不一定是应用本身的问题。尤其是 AI 服务链路比较长NestJS ↓ LangChain ↓ DNS ↓ K3s ↓ Nginx ↓ LiteLLM ↓ vLLM ↓ LLM任何一层出现路由或者节点不一致都可能最终表现成404 MODEL_NOT_FOUND所以排查时最好采用从上到下逐层绕过而不是一直在 LangChain 代码里寻找问题。本案例最终确认NestJS ✅ LangChain ✅ K3s Pod ✅ CoreDNS ✅ LiteLLM ✅ vLLM ✅ 模型 ✅ DNS 多 IP ⚠️ 部分 IP ❌通过固定 K3s Pod 内的域名解析到正常 IP 后问题得到解决。