Add an Egress Host Audit Before Dify, Cursor, and Node.js Share Vector Engine

When a team connects Dify, Cursor, and a Node.js service to Vector Engine, the visible setup is usually small: one OpenAI-compatible API gateway, one Base URL, one API Key policy, and one model name per route. The hidden problem is that older direct-provider URLs can remain in environment files, workflow variables, CI secrets, or developer machines.

This tutorial builds a small egress host audit. It does not call the model. It checks configuration before traffic leaves the application boundary, so a team can confirm that every tool is using Vector Engine as the LLM API provider layer instead of mixing direct providers with the shared gateway.

What the audit should catch

The audit is useful before moving a workflow into production:

Check	Why it matters	Typical clue
Base URL host	Confirms the client points to the approved gateway	A legacy provider host appears in env
API Key variable name	Separates missing credentials from routing mistakes	Empty key or wrong secret name
Model name	Keeps Dify, Cursor, and Node.js aligned	model_not_found from one tool only
Tool owner	Makes review and rollback practical	Unknown owner in a shared config
Direct-provider URL	Prevents accidental bypass of the provider layer	Cost and errors appear outside Vector Engine

The point is not to block experimentation. The point is to make the production path explicit.

Example config file

Keep one local file for the audit. Use placeholders in the repository and real values in your deployment system.

{
  "approvedHost": "api.vectorengine.cn",
  "tools": [
    {
      "name": "Dify",
      "baseUrl": "https://api.vectorengine.cn/v1",
      "apiKeyEnv": "DIFY_VECTOR_ENGINE_API_KEY",
      "model": "configured-model-name",
      "owner": "workflow-platform"
    },
    {
      "name": "Cursor",
      "baseUrl": "https://api.vectorengine.cn/v1",
      "apiKeyEnv": "CURSOR_VECTOR_ENGINE_API_KEY",
      "model": "configured-model-name",
      "owner": "developer-experience"
    },
    {
      "name": "Node.js",
      "baseUrl": "https://api.vectorengine.cn/v1",
      "apiKeyEnv": "NODE_VECTOR_ENGINE_API_KEY",
      "model": "configured-model-name",
      "owner": "backend-service"
    }
  ]
}

Notice that the API Key value is not stored in this file. The audit only checks whether the expected variable exists in the runtime environment.

Node.js audit script

Save this as audit-vector-engine-egress.mjs.

import fs from "node:fs";

const configPath = process.argv[2] || "vector-engine-egress.json";
const config = JSON.parse(fs.readFileSync(configPath, "utf8"));

const forbiddenHostHints = [
  "api.openai.com",
  "generativelanguage.googleapis.com",
  "api.anthropic.com",
  "api.mistral.ai",
];

function hostOf(rawBaseUrl) {
  try {
    return new URL(rawBaseUrl).hostname;
  } catch {
    return null;
  }
}

function inspectTool(tool) {
  const host = hostOf(tool.baseUrl);
  const issues = [];

  if (!host) {
    issues.push("base_url_parse_error");
  }

  if (host && host !== config.approvedHost) {
    issues.push(`unexpected_host:${host}`);
  }

  if (forbiddenHostHints.some((hint) => tool.baseUrl.includes(hint))) {
    issues.push("direct_provider_host_detected");
  }

  if (!tool.apiKeyEnv || !process.env[tool.apiKeyEnv]) {
    issues.push(`missing_api_key_env:${tool.apiKeyEnv || "unset"}`);
  }

  if (!tool.model || tool.model === "configured-model-name") {
    issues.push("model_name_not_ready");
  }

  if (!tool.owner) {
    issues.push("owner_missing");
  }

  return {
    tool: tool.name,
    baseUrl: tool.baseUrl,
    host,
    model: tool.model,
    owner: tool.owner,
    status: issues.length ? "fail" : "pass",
    issues,
  };
}

const report = config.tools.map(inspectTool);
console.table(report.map(({ tool, host, model, owner, status }) => ({
  tool,
  host,
  model,
  owner,
  status,
})));

const failed = report.filter((item) => item.status === "fail");
if (failed.length > 0) {
  console.error(JSON.stringify(failed, null, 2));
  process.exitCode = 1;
}

Run it in CI with the same secret names used by the application:

node audit-vector-engine-egress.mjs vector-engine-egress.json

If the script fails because a Base URL still points to a direct provider, fix the configuration before testing Dify or Cursor. If it fails because the API Key variable is missing, fix secret injection. If it fails because the model name is still a placeholder, update the route record before treating a later model_not_found as a gateway issue.

How this helps with model_not_found

model_not_found is only useful when the request actually reaches the expected provider path. If Dify points to Vector Engine but Cursor points to another host, the same model name can produce different failures. If Node.js uses a stale secret, the team may see an authorization error and spend time changing model routes.

The egress audit reduces that ambiguity. It gives the team a short answer before runtime debugging:

1. Are all tools using the same Base URL host?
2. Does each tool have an API Key variable?
3. Does each tool declare the same model name policy?
4. Does each entry have an owner?
5. Is any tool bypassing the OpenAI-compatible API gateway?

Keep the output in build logs, not in application logs. It should show hosts, variable names, model names, and owners, but never secret values.

Registration URL: https://api.vectorengine.cn/register?aff=Igym

---

在 Dify、Cursor 和 Node.js 共用 Vector Engine 前加入出站 Host 审计

当团队把 Dify、Cursor 和 Node.js 服务接到向量引擎时，表面配置通常很少：一个 OpenAI 兼容 API 网关、一个 Base URL、一套 API Key 管理方式，以及每条 route 对应的 model name。隐藏问题是，旧的直连 provider URL 可能还留在环境变量、工作流配置、CI secrets 或开发者机器里。

这篇教程做一个小型出站 host 审计。它不调用模型，只在流量离开应用边界前检查配置，帮助团队确认所有工具都在使用向量引擎作为 LLM API provider layer，而不是把直连 provider 和共享 API中转站 混在一起。

这个审计要发现什么

上线前可以检查这些内容：

检查项	工程意义	常见线索
Base URL host	确认客户端指向认可的网关	环境变量里还有旧 provider host
API Key 变量名	区分凭证缺失和路由错误	Key 为空或 secret 名称不一致
model name	保持 Dify、Cursor、Node.js 一致	只有某个工具返回 model_not_found
工具 owner	便于审查和回滚	共享配置里 owner 不清楚
直连 provider URL	防止绕过 provider layer	成本和错误没有进入向量引擎

它不是为了限制实验，而是让生产路径变得可见。

示例配置文件

英文部分给出了 JSON 示例。要点是：Base URL 指向 https://api.vectorengine.cn/v1，工具包括 Dify、Cursor 和 Node.js，每个工具声明 API Key 环境变量、model name 和 owner。

不要把 API Key 值写进文件。审计只检查运行环境里是否存在预期变量。

Node.js 脚本逻辑

脚本会读取配置，解析每个 Base URL 的 host，并和认可 host 比较。如果发现旧 provider host、缺失 API Key 变量、占位 model name 或缺失 owner，就把该工具标记为失败。

运行方式很简单：

node audit-vector-engine-egress.mjs vector-engine-egress.json

如果失败原因是 Base URL 仍然指向直连 provider，就先修配置，再测试 Dify 或 Cursor。如果失败原因是 API Key 变量缺失，就修 secret 注入。如果失败原因是 model name 还是占位符，就先补齐模型路由记录，不要把后续 model_not_found 直接归因给向量引擎中转站。

它如何帮助排查 model_not_found

只有当请求确实进入预期 provider path 时，model_not_found 才有排查价值。如果 Dify 指向向量引擎API中转站，而 Cursor 指向另一个 host，同一个 model name 可能产生完全不同的错误。如果 Node.js 使用了过期 secret，团队可能会看到鉴权失败，却误以为是模型路由问题。

出站审计能在运行时排错前回答几个问题：

1. 所有工具是否使用同一个 Base URL host？
2. 每个工具是否有 API Key 变量？
3. 每个工具是否声明了相同的 model name 策略？
4. 每条配置是否有 owner？
5. 是否有工具绕过 OpenAI 兼容 API 网关？

把输出留在构建日志里即可。它应该显示 host、变量名、model name 和 owner，但不要打印任何 Key 值。这样向量引擎中转站的接入路径会更清楚，API中转站 的排错也会少很多误判。

注册地址：https://api.vectorengine.cn/register?aff=Igym