NessGate

NessGate

向 NessGate 提供一个域名和客户端的能力，它就会告诉你客户端如何连接，以及还缺少什么。 一次调用即可将“这是一个域名”转化为具体且有来源依据的连接方案：使用哪种协议、哪个端点、哪种传输方式，以及服务发布的确切身份验证要求；如果暂时无法连接，也会指出服务缺少的确切字段。

curl -sX POST https://nessgate.com/connect/supabase.com \
  -H 'content-type: application/json' \
  -d '{"client":{"supports":[{"protocol":"mcp","auth":["oauth2","none"]}]}}'

{
  "domain": "supabase.com",
  "outcome": "credentials-required",          // ready | credentials-required | incomplete | no-compatible-method
  "connection": {
    "protocol": "mcp",  "transport": "streamable-http",
    "endpoint": "https://mcp.supabase.com/mcp",
    "auth": { "type": "oauth2",
              "authorizationEndpoint": "https://api.supabase.com/v1/oauth/authorize",
              "tokenEndpoint":         "https://api.supabase.com/v1/oauth/token",
              "scopes": ["projects:read", "database:write", "…"] }
  }
}
// → everything needed to connect is known; you just supply your own credentials
//   (which never touch NessGate). No scores; each field links back to its source.

五种明确的结果，绝不猜测：ready（可立即连接，无需凭据）、credentials-required（所需信息已齐备——请提供你自己的密钥）、incomplete（服务发布的信息不完整——NessGate 会指出缺少的确切字段）、broken（声明的位置有响应，但内容与其自身声明相矛盾）、no-compatible-method（客户端不支持任何可用方式）。更偏好按资源查看？在 /explore 后添加 ?readiness=1。更偏好域名发布内容的原始列表？那就是原有的解析器 GET /discover/{domain}——保持不变，仍可使用。

为什么不自己构建？

你当然可以——这并非不可能，只是要一直维护下去。要将域名转换为可用的连接，你得读取并跟踪每项发现标准（ARD、A2A、llms.txt、api-catalog、OpenAPI、ORD、host-meta、ANP、UCP、AID、MCP、GB/Z 185.4……），理解每项标准的身份验证机制（OpenAPI 安全方案、MCP OAuth 元数据链 RFC 9728 → RFC 8414、A2A 卡片方案），处理服务器的各种特殊情况、超时、重定向，并在每一跳确保 SSRF 安全；还得将所有信息规范化为统一格式，并随着协议变化持续更新。NessGate 正是为此而建：按需读取，不存储已发现的域名或资源数据，并保持中立——这样你只需编写自己的 Agent，而不必构建兼容层。它免费、开源（Apache-2.0），且可独立实现；即使 nessgate.com 消失，每个域名的文件仍会保留在域名自身上。

反向方向——描述传入的自动化调用方声明了什么、能证明什么——由实验性软件包 @nessgate/inspect（0.x）负责：分层且注明来源的事实（已声明／经密码学验证／经网络验证／由目录归属确认），不作判断，不打分。请参阅 docs/integrations.md §5。

正在发布服务？趁 Agent 发现之前，先自行测试：

npx @nessgate/resolver yourdomain.com    # exit 0 = agents can connect; otherwise it names the exact missing field

在你的计算机上运行开放的就绪状态判定逻辑（不会向任何地方报告），进行 3 次观测；严格模式下，端点不稳定即判定失败。将它加入 CI，确保你的发布内容始终可连接。

现已上线：https://nessgate.com · 规范 · 章程 · API

_{NessGate 只会读取域名已发布的标准；它不定义任何标准，也不存储任何内容。域名始终是权威来源。}

使用方法

可嵌入库——零依赖，直接获取目标域名内容（运行时不依赖 nessgate.com），可在任何支持 fetch 的环境中运行——Node、Deno、Workers 和 Agent 运行时。（它也能在浏览器中运行，但浏览器只能读取发送了 CORS 标头的其他域名，而大多数 .well-known 文件都不会发送此类标头——因此，在浏览器中解析任意域名时，请使用下方托管的端点；该端点开放 CORS。）发布于 @nessgate/resolver：

import { resolve } from "@nessgate/resolver";      // or "https://nessgate.com/resolver.mjs"
const { resources } = await resolve("example.com");

托管端点——开放 CORS，无需身份验证：

curl https://nessgate.com/discover/example.com

MCP——将相同的查询作为工具（discover_domain）提供，地址为 https://nessgate.com/mcp。它已列入 官方 MCP 注册表，名称为 com.nessgate/nessgate（已通过域名验证的远程服务），因此支持 MCP 的客户端可直接安装。

集成（约 5 行）

向 Agent 提供一个域名，即可获得要使用的内容——无需针对每种标准编写代码。将以下内容接入工具、 检索步骤或引导流程：

import { resolve } from "@nessgate/resolver";           // dependency-free, no key, no account
const { resources } = await resolve(domain);            // reads the domain directly
for (const r of resources)
  console.log(r.type, r.url, "←", r.sourceUrl);         // normalized record + where it came from
// each r: { source, type, url, sourceUrl } — pick the one your agent needs (OpenAPI, A2A, MCP, …)

没有 SDK？托管端点只需发送一次 HTTP GET（GET https://nessgate.com/discover/{domain}，支持开放 CORS，无需身份验证），MCP 工具 discover_domain 返回相同格式。新增标准只需在上游添加一个适配器——集成无需改动。

完整集成指南——包括库、HTTP 和 MCP 客户端配置（含供仅支持 stdio 的客户端使用的 mcp-remote 桥接程序）：docs/integrations.md。

原则

NessGate 是免费的中立基础设施——请参阅章程。使用或读取它永远免费，不出售排名或展示位置（没有排名或展示位置），不保留账户，也不存储任何域名数据。它按需读取域名（答案在边缘缓存，最长 10 分钟），从不爬取或编入索引，也不对所有权或安全性作任何声明——它只报告域名提供的内容，并链接回各个来源。规范是开放的，参考实现采用 Apache-2.0 许可： 任何人都可以运行自己的解析器；即使 nessgate.com 消失，每个域名的文件仍会保留在该域名上。

架构

• 一个无状态的 Cloudflare Worker（src/worker.js）负责提供静态网站 （public/，通过启用 run_worker_first 的 assets 绑定）、解析器 API、MCP 服务、每个域名的页面以及站点地图。没有数据库。
• 解析器（GET /discover/{domain}，以及可嵌入的 public/resolver.mjs）读取 域名发布的内容，将其规范化为一个答案，直接获取域名内容，且不存储任何数据。答案实时计算，并在边缘缓存 10 分钟。一致性测试确保 Worker 和库的规范化结果逐字节一致，同时确保 packages/resolver/index.mjs（npm 包）与 public/resolver.mjs 逐字节一致。
• 适配器架构——四种发现渠道。 每种受支持的标准都有一个小型独立适配器，每个适配器都通过以下四种渠道之一定位其文档：
  • well-known — 对域名上的固定路径（或多个路径）执行 GET：llms.txt、ard-catalog （ARD / ai-catalog）、a2a-agent-card（A2A）、api-catalog（RFC 9727）、ai-info.json、 openapi、ord（Open Resource Discovery）、awp（草案）、host-meta（RFC 6415）、 anp（Agent Network Protocol /.well-known/agent-descriptions）以及 ucp（Universal Commerce Protocol /.well-known/ucp）。
  • link-rel — 解析主页中的 <link rel="ard">，然后对目标执行 GET（ard-link）。
  • robots — 解析 /robots.txt 中的 Agentmap: 指令，然后对目标执行 GET （ard-agentmap）。
  • dns — 在 _agent.<domain> 上通过 DoH 查询 TXT 记录（aid：v=aid1;u=<uri>;p=<proto>;a=<auth>）。 ARD： NessGate 实现了 ARD 的规范性域名解析——它会获取 /.well-known/ard.json 并遵循 <link rel="ard"> 关系（ARD v0.91 §5.1 中两者均为 MUST），还会处理 robots 的 Agentmap: 表面。ARD 可选的页内 JSON-LD 只能通过 通用网页爬取发现，而 NessGate 不会执行此类爬取；ARD 的 DNS 机制在 §5.1 中有描述，但 尚未规范化（没有记录类型或参数）。两者都未实现——发布猜测的记录不算符合规范。ANP 和 UCP 正在兴起；AID TXT 记录（_agent 上的 v=aid1）和 AWP 仍处于草案阶段，按原样读取，不声称已采用。注意： aid 适配器指的是 AID TXT 机制，不是 IETF DNS-AID 草案（_agents.<domain> 上的 SVCB——这是另一种尚未实现的机制）。
• GB/Z 185（中国，智能体互联）——185.4 支持，185.5 受限。 NessGate 会规范化 GB/Z 185.4 智能体描述（“ACS”）：ACS 是带有 GB/Z 扩展的 A2A 系列卡片（包括智能体身份代码 aic、mTLS 方案和 certificate 块），系统会按内容识别并标记为 gbz-185-4，同时保留这些字段及其来源信息。识别以域名为先：在 NessGate 已读取的智能体描述位置提供的 ACS 会被规范化——不会猜测 GB/Z 专用的 .well-known 路径。 GB/Z 185.5 发现是一种联邦网关服务，没有域名原生位置，因此不属于托管解析器，也绝不会自动发现。可嵌入式库通过可选启用、仅限 Node.js 的调用提供此功能（resolve(domain, { gbz: { gatewayUrl, fetch, query } })），该调用会向参考实现的真实 …/acps-adp-v2/discover 端点发送 POST 请求，并使用调用方提供的已认证 fetch（自行提供 mTLS/OIDC——NessGate 不嵌入任何凭据），再规范化返回的 ACS 记录。不猜测端点，不虚假声称符合规范。
• Cloudflare KV（NESSGATE_KV）仅存储按 IP 键控的近似每小时速率限制计数器，并在一小时内过期。不存储其他内容。
• 速率限制：在近似 KV 每小时上限之前使用 Cloudflare 原生边缘限流器（突发限流、按 colo 限流且最终一致——设计上为近似值）。用于滥用防护，而非精确的全局计量。
• SSRF 防护：DoH 预检会过滤私有／保留 IP，仅允许同域重定向（≤ 3），大小上限为 1 MB，超时为 8 s，且仅限 HTTPS。探测只会对公开的 well-known 路径发起只读 GET 请求；src/worker.js 中记录了 DNS 重绑定的 TOCTOU 窗口，在此处无关紧要（Worker 出站网络后没有私有网络，且探测不做任何断言）。
• 无账号、无电子邮件、不存储域名数据。

端点

端点	用途
GET /discover/{domain}	**解析器。**读取该域名通过受支持的适配器发布的内容（llms.txt、通过 well-known 路径发布的 ARD/ai-catalog、rel="ard" 链接和 robots Agentmap:；A2A Agent 卡片、RFC 9727 api-catalog、ai-info.json、OpenAPI、ORD、AWP、host-meta、ANP、UCP、AID、GB/Z 185.4），并返回一个标准化结果 — {domain, provenance, note, discovered[], resources[], checked[]}，其中每项资源都带有 source 和原生 sourceUrl。开放 CORS，无需身份验证；不存储已发现的域名或资源数据，也不进行爬取；缓存 10 分钟，速率限制为每个 IP 每小时 120 次。
GET /explore/{domain}	**基于证据的解析器（v2，增量式）。**包含 /discover 返回的所有内容，此外还进行有限的委托发现：跟进域名声明的明确机器可读指针（llms.txt 索引中的链接、ARD/api-catalog 条目），深度最多为 2 — 仅当发布者指定目标时才会跨主机；并联合查询官方 MCP Registry，获取该域名已验证的命名空间。每条记录都带有 evidence 类别（publisher-hosted / publisher-declared / namespace-verified）和 provenance 链。严格限制范围（深度 ≤2，≤8 个主机，≤24 次请求，全局字节数上限，每一跳都进行 SSRF 检查）；无状态，不爬取，不使用 AI，也不声称所有权。添加 ?org=1（组织发现）后，还会探测一组有限的、可能属于同一可注册域名的主机（主页链接到的子域名 + 一小组常见主机名，最多 6 个主机 × 3 条路径），并仅将已验证的资源报告为 same-domain-host — 解决“资源位于 developers.example.com，而非 example.com”的情况。/discover 保持不变。
GET /explore/{domain}?readiness=1	**连接就绪状态（可选，增量式）。**包含 /explore 返回的所有内容，此外还会根据服务自身发布的元数据，为每项可连接资源提供 readiness 区块：ready / credentials-required / incomplete（其中 missing[] 会指出具体缺失的发布字段）/ broken（已声明但经验证无法正常工作）；只读，不评分。解析 OpenAPI servers[]+securitySchemes、A2A 卡片和 MCP OAuth 元数据链（RFC 9728 → RFC 8414）。范围受限且有 SSRF 防护；凭据不会传给 NessGate。默认的 /explore（不带标志）保持不变。
POST /connect/{domain}	**连接计划。**请求体 { client: { supports:[{protocol,versions?,transports?,auth?}], prefer? } }。根据域名发布的内容匹配客户端声明的能力（确定性交集，不评分），并返回一种结果 — ready / credentials-required / incomplete / broken / no-compatible-method — 以及连接计划（端点、传输方式、版本、身份验证元数据）和对应的来源信息。只读；客户端能力仅作为输入（不存储任何内容）；客户端直接连接。
POST /mcp	Model Context Protocol 服务（Streamable HTTP、无状态、无需身份验证），提供三个只读工具：discover_domain（与 /discover 返回相同结果）、connect_domain（与 POST /connect 相同）和 check_readiness（与 /explore?readiness=1 相同）。
GET /{domain}	面向用户的域名页面 — 以人类可读形式呈现解析器（实时发现）。
GET /resolver.mjs	可嵌入的解析器库（也可通过 npm 获取，包名为 @nessgate/resolver）。
GET /openapi.json、/llms.txt、/spec、/sitemap.xml、/robots.txt、/.well-known/security.txt、/.well-known/api-catalog	机器发现与文档

运维手册

• **部署流程：**提交 → npm run deploy（运行完整回归测试套件作为部署前的强制门禁，然后通过 BUILD_ID 将构建与 git SHA 关联）→ npm run check （回归测试 + 线上冒烟检查，包括验证生产环境的 /version 与本地 HEAD 一致）→ 推送。CI（GitHub Actions）会在每次推送时运行回归测试套件。由于部署从工作站执行，部署脚本门禁是实际的生产环境门禁。
• **构建验证：**每个响应中的 GET /version 和 X-NessGate-Build 标头都会标识确切的已部署提交。
• 测试：npm test — 针对安全关键逻辑的无网络回归测试套件（规范化、SSRF/私有 IP 检测、探测内容验证、精简规范化，以及 worker↔library↔npm 一致性）。
• 回滚：npm run rollback（或 npx wrangler rollback [version-id]；版本由 npx wrangler deployments list 列出）。
• 日志：npx wrangler tail nessgate。
• **CSS 变更：**更新所有页面样式表链接中的 ?v=N（资源会被缓存；未更新版本号的 CSS 变更不会传递到浏览器）。

配置

wrangler.toml 绑定了：资源（run_worker_first）、KV 和一个 [[ratelimits]] 绑定。没有 D1 数据库、没有 cron 触发器，也没有密钥——解析器是无状态的。

npm 包

packages/resolver/ 通过 GitHub Actions Trusted Publishing（OIDC，无令牌，并包含来源证明）发布为 @nessgate/resolver — 详见 .github/workflows/publish-resolver.yml。一致性测试确保 index.mjs 与 public/resolver.mjs 逐字节相同。

许可证与贡献

参考实现采用 Apache-2.0 许可证（LICENSE）；WordPress 插件采用 GPL 许可证，这是 WordPress.org 的要求。该协议是开放的，可由任何人独立实现——请参阅 CONTRIBUTING.md、TRADEMARK.md 中的命名/商标政策，以及章程。任何人都可以无需许可构建兼容的解析器；独立实现是我们的目标，而非威胁。规范解析器/规范化逻辑位于 public/resolver.mjs 和 src/worker.js（由一致性测试确保逐字节相同）。

安全联系信息

[email protected]（参见 /.well-known/security.txt）， [email protected]、[email protected]、[email protected]。