OpenRouter bị sập? Cách chuyển dự phòng mà không cần đổi code

Khi mọi người tìm kiếm OpenRouter Down, họ thường cần câu trả lời nhanh cho hai câu hỏi: OpenRouter có thực sự bị sập không, và làm thế nào để tôi giữ cho các yêu cầu tiếp tục chạy mà không phải viết lại ứng dụng?

Câu trả lời an toàn nhất là đừng hoảng loạn chuyển model trong code. Trước hết, hãy xác nhận vấn đề là trên toàn bộ OpenRouter, do nhà cung cấp cụ thể, do tài khoản cụ thể, hay do hàng đợi retry của chính bạn. Sau đó, hãy đưa cơ chế failover vào cấu hình: kiểm tra trạng thái, ngân sách retry, fallback nhà cung cấp, fallback model, và một base_url tương thích OpenAI có thể thay thế.

Ngày kiểm tra: 13 tháng 10, 2026. Đừng coi bài viết này là bằng chứng rằng OpenRouter hiện đang bị sập. Hãy kiểm tra trang trạng thái OpenRouter và log của chính bạn trước khi bắt đầu xử lý sự cố.

Câu trả lời ngắn

Nếu OpenRouter bị sập, hoặc nếu một route của OpenRouter đang lỗi, hãy dùng thứ tự sau:

1. Kiểm tra https://status.openrouter.ai/ và log lỗi của bạn.
2. Tách lỗi nền tảng OpenRouter khỏi lỗi model/nhà cung cấp upstream.
3. Tôn trọng Retry-After trên các phản hồi 429, 503, và 402 với ngân sách in-flight.
4. Giữ provider.allow_fallbacks được bật trừ khi có quy định tuân thủ yêu cầu khác.
5. Thêm fallback model thông qua cấu hình request nơi thỏa thuận chất lượng phản hồi cho phép.
6. Đặt API gateway hoặc endpoint dự phòng của bạn sau một biến môi trường để bạn có thể chuyển base_url mà không cần sửa code ứng dụng.

Điểm cuối cùng đó mới chính là cách “không cần đổi code” thực sự. Ứng dụng của bạn nên đọc endpoint từ cấu hình:

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

Trong lúc sự cố xảy ra, thay đổi vận hành của bạn sẽ là:

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

SDK của bạn vẫn giữ nguyên.

OpenRouter có bị sập không?

Đừng suy ra OpenRouter Down chỉ từ một request thất bại. Một request lỗi có thể có nghĩa là:

Tài liệu lỗi của OpenRouter cho biết 502 có thể có nghĩa là model được chọn đang bị lỗi hoặc trả về phản hồi không hợp lệ, trong khi 503 có thể có nghĩa là không có provider model nào khả dụng đáp ứng yêu cầu định tuyến. Cùng tài liệu đó cũng nói OpenRouter có thể trả về Retry-After trên 429, 503, và một số phản hồi 402 với ngân sách in-flight. Nguồn: OpenRouter errors and debugging.

OpenRouter từng có các đợt gián đoạn công khai trước đây. Bài postmortem ngày 17 và 19 tháng 2 năm 2026 mô tả các lỗi API do một phụ thuộc caching của bên thứ ba và lưu ý rằng một số người dùng đã thấy các lỗi 401 gây nhầm lẫn trong lúc sự cố. Bài viết lịch sử đó hữu ích làm bối cảnh, nhưng không phải bằng chứng về một sự cố hiện tại. Nguồn: OpenRouter outage postmortem.

Năm phút đầu tiên: phân loại sự cố OpenRouter Down

Dùng danh sách kiểm tra này trước khi chuyển lưu lượng.

Lỗi lớn nhất trong một sự cố OpenRouter Down là để mọi worker retry ngay lập tức. Một cơn bão retry có thể biến lỗi của một nhà cung cấp thành vấn đề hàng đợi trên toàn nền tảng ngay trong ứng dụng của bạn.

Chuyển dự phòng mà không cần thay đổi code

Mẫu không cần đổi code rất đơn giản: giữ cách dùng SDK ổn định và làm cho route có thể cấu hình được.

import OpenAI from "openai";

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

Sau đó hãy giữ việc chọn endpoint trong biến môi trường, cấu hình triển khai, feature flags, hoặc trình quản lý bí mật của bạn:

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

Điều này hoạt động vì phần quickstart của OpenRouter nói rằng API của họ có thể được dùng thông qua OpenAI SDK bằng cách trỏ SDK tới OpenRouter. Kiểu tích hợp giống hệt này chính là lý do khiến một gateway dự phòng tương thích OpenAI trở nên thực tế. Nguồn: OpenRouter quickstart.

Dùng Fallback Nhà Cung Cấp Trước Khi Đổi Model

Nếu OpenRouter vẫn truy cập được nhưng một nhà cung cấp đang gặp vấn đề, fallback nhà cung cấp là lựa chọn ít rủi ro nhất. Bạn giữ nguyên hợp đồng của model và để routing thử một nhà cung cấp đủ điều kiện khác.

Tài liệu routing nhà cung cấp của OpenRouter nói rằng theo mặc định, các request được cân bằng tải qua các nhà cung cấp hàng đầu để tối đa hóa thời gian hoạt động, và đối tượng provider có bao gồm allow_fallbacks, mặc định là true. Tài liệu cũng cảnh báo rằng việc đặt sort hoặc order sẽ thay đổi hành vi cân bằng tải, và các bộ lọc nhà cung cấp cứng có thể làm giảm không gian routing. Nguồn: OpenRouter provider routing.

Bắt đầu với cách này:

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

Hãy cẩn thận với cách này trong lúc xảy ra sự cố:

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

Routing nghiêm ngặt có thể đúng với các chính sách tuân thủ, lưu giữ dữ liệu, khu vực, hoặc giá. Nhưng routing nghiêm ngặt không phải là một cài đặt về độ tin cậy. Nếu bạn cần routing nghiêm ngặt cho các workload nhạy cảm, hãy tạo một luồng riêng không nhạy cảm có thể chuyển dự phòng linh hoạt hơn.

Chỉ Thêm Model Fallback Khi Đầu Ra Có Thể Hoán Đổi Cho Nhau

Model fallback mạnh hơn provider fallback. Nó có thể giữ cho ứng dụng tiếp tục hoạt động khi model chính bị sập, bị giới hạn tốc độ, hoặc bị chặn, nhưng nó cũng có thể làm thay đổi phong cách đầu ra, độ trễ, chi phí, độ dài ngữ cảnh, hành vi công cụ, và kết quả đánh giá.

Tài liệu model fallback của OpenRouter nói rằng tham số models cho phép bạn cung cấp các ID model theo thứ tự ưu tiên. Nếu model đầu tiên trả về lỗi, OpenRouter sẽ thử model tiếp theo. Tài liệu liệt kê giới hạn tốc độ và thời gian ngừng hoạt động trong số các lỗi có thể kích hoạt fallback. Nguồn: OpenRouter model fallbacks.

Hãy dùng model fallback cho các tác vụ có cam kết tương đương lỏng lẻo:

{
  "models": [
    "anthropic/claude-sonnet-4.5",
    "openai/gpt-4o",
    "google/gemini-2.5-pro"
  ],
  "messages": [{ "role": "user", "content": "Tóm tắt chuỗi hỗ trợ này." }]
}

Tránh fallback model âm thầm cho các tác vụ mà model chính xác là một phần của cam kết sản phẩm:

Một Chính Sách Sự Cố Thực Tế

Chính sách này cố tình đơn giản. Nó giữ cho công việc ứng phó OpenRouter Down vận hành được thay vì kịch tính hóa.

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

Các trường quan trọng cần ghi log là:

Flatkey phù hợp ở đâu

Flatkey hữu ích khi bạn muốn playbook OpenRouter Down nằm bên ngoài mã ứng dụng. Định vị sản phẩm của Flatkey là một cổng API LLM hợp nhất: một key, một số dư, và một endpoint tương thích OpenAI để định tuyến qua các mô hình văn bản, hình ảnh và video chính thức. Trong mẫu sự cố này, giá trị thực tế là ở vận hành:

• Giữ ứng dụng của bạn trên một hình dạng client tương thích OpenAI.
• Định tuyến một workload qua base_url dự phòng mà không cần thay đổi logic ứng dụng.
• Tập trung allowlist mô hình, sub-key, nhật ký yêu cầu, kiểm soát ngân sách và chính sách fallback.
• So sánh hành vi của cổng bằng bằng chứng từ yêu cầu thay vì lời kể truyền miệng.

Đừng chuyển mọi workload trong một sự cố nhỏ. Hãy chuyển trước một workload đại diện, theo dõi tỷ lệ lỗi, độ trễ, mô hình được chọn, lý do fallback và chi phí, rồi mới quyết định có mở rộng việc chuyển đổi hay không.

Các bài đọc tiếp theo hữu ích:

• Giới hạn tốc độ của OpenRouter
• Định tuyến fallback API LLM
• Chiến lược fallback mô hình
• Quản lý hạn ngạch API AI
• Hướng dẫn nhanh API Flatkey

Câu hỏi thường gặp về OpenRouter Down

OpenRouter có đang bị sập ngay bây giờ không?

Trước hết, hãy kiểm tra trang trạng thái của OpenRouter. Bài viết này giải thích cách phản ứng khi các tìm kiếm OpenRouter Down tương ứng với một sự cố thực hoặc lỗi của nhà cung cấp cục bộ; nó không khẳng định rằng OpenRouter đang sập ngay bây giờ.

Tôi nên làm gì trước tiên nếu OpenRouter bị sập?

Tạm dừng các lần retry mạnh, kiểm tra mã trạng thái và bảo toàn lưu lượng tương tác. Nếu sự cố được xác nhận, hãy ưu tiên fallback nhà cung cấp trước fallback mô hình, và ưu tiên chuyển đổi cấu hình base_url trước khi triển khai code.

Tôi có thể chuyển dự phòng khỏi OpenRouter mà không cần thay đổi code không?

Có, nếu ứng dụng của bạn đã đọc endpoint tương thích OpenAI từ cấu hình. Đặt baseURL hoặc base_url sau một biến môi trường, giữ nguyên hình dạng lời gọi SDK, và chuyển endpoint trong cấu hình triển khai.

Tôi có nên dùng các fallback mô hình của OpenRouter trong thời gian gián đoạn không?

Chỉ nên dùng fallback mô hình khi mô hình dự phòng chấp nhận được cho tác vụ đó. Chúng phù hợp với nhiều quy trình nội bộ, nhưng không phù hợp cho các lần eval, đầu ra chịu quy định, hoặc các trường hợp khách hàng đã được hứa một mô hình cụ thể.

Giải pháp dài hạn an toàn nhất cho rủi ro OpenRouter Down là gì?

Thiết kế để có tính di động ở cấp tuyến: base_url có thể cấu hình, ghi log ở cấp yêu cầu, ngân sách retry, fallback nhà cung cấp, các hợp đồng fallback mô hình đã được kiểm thử, và một đường dự phòng cổng tương thích OpenAI. Mục tiêu không phải là tránh mọi lần gián đoạn; mà là làm cho việc chuyển dự phòng trở nên bình thường.