OpenRouter 出现故障？如何在不更改代码的情况下切换故障转移

当人们搜索 OpenRouter 出现故障 时，他们通常需要尽快得到两个答案：OpenRouter 是否真的宕机了，以及我该如何在不重写应用的情况下让请求继续运行？

最安全的做法不是在代码里慌乱地切换模型。先确认问题是 OpenRouter 全局性故障、特定提供商故障、账户特定问题，还是你自己的重试队列问题。然后把故障转移移到配置中：状态检查、重试预算、提供商回退、模型回退，以及可替换的兼容 OpenAI 的 base_url。

检查日期：2026 年 10 月 13 日。不要把本文当作 OpenRouter 当前已宕机的证据。在启动事件处理前，请先查看 OpenRouter 状态页面 和你自己的日志。

简短答案

如果 OpenRouter 宕机了，或者某条 OpenRouter 路由失败了，请按以下顺序处理：

1. 检查 https://status.openrouter.ai/ 和你的错误日志。
2. 区分 OpenRouter 平台错误与上游模型/提供商错误。
3. 对于 429、503 以及 in-flight-budget 402 响应，遵守 Retry-After。
4. 除非合规规则另有要求，否则保持 provider.allow_fallbacks 启用。
5. 在响应质量契约允许的情况下，通过请求配置添加模型回退。
6. 将你的 API 网关或备用端点放在环境变量后面，这样你就可以在不编辑应用代码的情况下切换 base_url。

最后这一点才是真正的“无需更改代码”的做法。你的应用应从配置中读取端点：

OPENAI_BASE_URL=https://openrouter.ai/api/v1
OPENAI_API_KEY=...

在事件期间，你的运维改动会变成：

OPENAI_BASE_URL=https://router.flatkey.ai/v1
OPENAI_API_KEY=...

你的 SDK 代码保持不变。

OpenRouter 宕机了吗？

不要因为一次请求失败就推断出 OpenRouter 出现故障。一次失败请求可能意味着：

OpenRouter 的错误文档说明，502 可能表示所选模型宕机或返回了无效响应，而 503 可能表示没有可用的模型提供商满足路由要求。相同文档还说明，OpenRouter 可能会在 429、503 以及某些 in-flight-budget 402 响应中返回 Retry-After。来源：OpenRouter 错误与调试。

OpenRouter 过去曾发生过公开故障。其 2026 年 2 月 17 日和 19 日的事后分析描述了由第三方缓存依赖导致的 API 失败，并指出在事件期间部分用户看到了令人困惑的 401 错误。那篇历史文章仅供背景参考，并不能证明当前存在故障。来源：OpenRouter 故障事后分析。

前五分钟：OpenRouter 故障分诊

在切换流量之前，先使用此检查清单。

在 OpenRouter 出现故障 事件期间，最主要的错误是让每个 worker 立即重试。重试风暴可能会把一个提供商错误变成你自己应用内部的平台级队列问题。

无需更改代码的故障转移

无需改代码的模式很简单：保持 SDK 用法稳定，并让路由可配置。

import OpenAI from "openai";

export const ai = new OpenAI({
  apiKey: process.env.OPENAI_API_KEY,
  baseURL: process.env.OPENAI_BASE_URL,
});

然后将端点选择保留在环境变量、部署配置、功能标志或你的密钥管理器中：

ai_gateway:
  primary:
    base_url: https://openrouter.ai/api/v1
    key_env: OPENROUTER_API_KEY
  backup:
    base_url: https://router.flatkey.ai/v1
    key_env: FLATKEY_API_KEY
  switch_policy:
    trigger: confirmed_platform_incident_or_error_budget_exhausted
    owner: on_call_engineer
    rollback: after_30_minutes_below_error_threshold

这之所以有效，是因为 OpenRouter 的快速入门说明其 API 可以通过将 SDK 指向 OpenRouter 来通过 OpenAI SDK 使用。相同的集成形式，正是让备用的、兼容 OpenAI 的网关变得可行的原因。来源：OpenRouter quickstart。

在更改模型之前先使用提供方回退

如果 OpenRouter 可达，但某个提供方出现问题，那么提供方回退是风险最低的做法。你保持相同的模型契约，并让路由尝试另一个符合条件的提供方。

OpenRouter 的提供方路由文档说明，默认情况下请求会在顶级提供方之间进行负载均衡，以最大化可用性，并且 provider 对象包含 allow_fallbacks，默认值为 true。文档还警告说，设置 sort 或 order 会改变负载均衡行为，而严格的提供方筛选可能会减少路由空间。来源：OpenRouter provider routing。

先从这个开始：

{
  "model": "anthropic/claude-sonnet-4.5",
  "messages": [{ "role": "user", "content": "..." }],
  "provider": {
    "allow_fallbacks": true
  }
}

在事故期间使用这个要小心：

{
  "provider": {
    "only": ["one-provider"],
    "allow_fallbacks": false
  }
}

严格路由可能适用于合规、数据保留、地域或定价策略。但严格路由不是可靠性设置。如果你出于敏感工作负载需要严格路由，请创建一条可更自由地进行故障转移的、独立的非敏感路径。

仅在输出可互换时添加模型回退

模型回退比提供方回退更强。它可以在主模型宕机、被限流或被阻止时保持应用运行，但它也可能改变输出风格、延迟、成本、上下文长度、工具行为和评估结果。

OpenRouter 的模型回退文档说明，models 参数允许你按优先级顺序提供模型 ID。如果第一个模型返回错误，OpenRouter 会尝试下一个模型。文档将限流和停机列为可触发回退的错误。来源：OpenRouter model fallbacks。

对于契约较宽松的任务，使用模型回退：

{
  "models": [
    "anthropic/claude-sonnet-4.5",
    "openai/gpt-4o",
    "google/gemini-2.5-pro"
  ],
  "messages": [{ "role": "user", "content": "Summarize this support thread." }]
}

对于产品保证中必须精确指定模型的任务，不要静默使用模型回退：

实用的事故策略

这项策略有意做得很“无聊”。它让 OpenRouter Down 的响应工作保持可操作，而不是戏剧化。

openrouter_down_policy:
  status_checks:
    - openrouter_status_page
    - synthetic_chat_completion
    - provider_error_rate_by_model
    - queue_retry_rate

  retry_budget:
    max_attempts: 3
    honor_retry_after: true
    jitter: true
    stop_retrying_on:
      - invalid_credentials
      - spent_budget
      - moderation_block
      - bad_request

  provider_fallback:
    default_allow_fallbacks: true
    loosen_provider_constraints_for:
      - non_sensitive_batch_jobs
      - internal_tools
      - support_summaries

  model_fallback:
    require_contract: equivalent_quality_or_validated_schema
    log_selected_model: true
    disallow_for:
      - evals
      - compliance_outputs
      - customer_promises_about_exact_model

  base_url_failover:
    primary: OPENAI_BASE_URL
    backup_env: OPENAI_BACKUP_BASE_URL
    switch_owner: on_call_engineer
    switch_requires:
      - confirmed_status_incident_or_internal_error_budget
      - rollback_plan
      - public_request_log_enabled

需要记录的关键字段是：

Flatkey 的适用位置

当你希望 OpenRouter Down 运行手册脱离应用代码时，Flatkey 就很有用。Flatkey 的项目定位是统一的 LLM API 网关：一个密钥、一个余额，以及一个与 OpenAI 兼容的端点，用于在官方文本、图像和视频模型之间进行路由。在这种事件模式下，它的实际价值在于运维层面：

• 让你的应用保持 OpenAI 兼容客户端的形态。
• 通过备用 base_url 路由工作负载，而无需更改应用逻辑。
• 集中管理模型允许列表、子密钥、请求日志、预算控制和回退策略。
• 基于请求证据而非传闻来比较网关行为。

在小规模事故期间，不要迁移所有工作负载。先迁移一个有代表性的工作负载，观察错误率、延迟、所选模型、回退原因和成本，然后再决定是否扩大切换范围。

接下来值得阅读：

• OpenRouter 速率限制
• LLM API 回退路由
• 模型回退策略
• AI API 配额管理
• Flatkey API 快速开始

OpenRouter Down 常见问题

OpenRouter 现在宕机了吗？

先查看 OpenRouter 状态页面。本文解释的是当 OpenRouter Down 搜索对应真实事件或本地提供方故障时该如何应对；它并不声称 OpenRouter 现在已经宕机。

如果 OpenRouter 宕机了，我首先应该做什么？

暂停激进重试，检查状态码，并保留交互式流量。如果事件已确认，优先进行提供方回退，再考虑模型回退；并优先采用 base_url 配置切换，而不是代码发布。

我可以在不更改代码的情况下从 OpenRouter 切换故障转移吗？

可以，前提是你的应用已经从配置中读取 OpenAI 兼容端点。把 baseURL 或 base_url 放到环境变量后面，保持 SDK 调用形态不变，并在部署配置中切换端点。

在故障期间我应该使用 OpenRouter 的模型回退吗？

只有当回退模型对任务是可接受的时候，才使用模型回退。它们适用于许多内部工作流，但不适用于评测、受监管输出，或已向客户承诺特定模型的场景。

针对 OpenRouter Down 风险，最安全的长期修复是什么？

按照路由级可移植性来设计：可配置的 base_url、请求级日志记录、重试预算、提供方回退、经过测试的模型回退契约，以及备用的 OpenAI 兼容网关路径。目标不是避免每一次宕机；而是让故障转移变得平淡无奇。