它還支持Gemini Buttons和Codex中轉，支持多帳戶切換、自定義API密鑰、Claude API、OpenAI兼容格式，有效避免帳戶封禁，OAuth集成可以快速添加帳戶池。
類似的項目包括： https://github.com/yushangxiao/claude2api
這些項目的核心要求是用戶希望將自己的帳戶轉換成API供更多人使用，網際網路上的一些拼車也與這些類似
1.項目居間核心定位
該項目的中文描述寫得更直接：
「自建Claude API行紀服務，支持多帳戶管理……一站式開源交通服務，允許Claude、OpenAI、Gemini和Droid訂閱以統一方式訪問，支持拼車共享、更高效的成本分擔以及原生工具的無縫使用。」（[GitHub][1]）
換句話說，它本質上是一個「中繼/代理/轉發」服務（relay service），用於在自己控制的伺服器上建立統一的入口點，前端或客戶端向這箇中繼服務發送請求，中繼服務再將請求轉發給多個後端AI服務（Claude、OpenAI、Gemini、Droid等）。此中繼還可以執行其他功能，例如帳戶管理，流量/費用統計和智能切換。
主要用途可以總結為：
- 將多個人工智慧服務帳戶聚集在一個「中繼」節點中。
- 將API密鑰分配給不同的消費者（或客戶端），並中繼控制訪問權限、速率、並發性等。
- 實現「拼車/共享訂閱/帳戶池」的目的，分攤成本。
- 避免前端或用戶直接暴露真實的後台帳戶（關鍵暴露、濫用風險）。
- 提高穩定性：如果帳戶或節點異常，可以自動切換或剔除中繼。
- 允許統一監控、統計令牌使用情況、性能指標等。
2.主要功能架構組件
根據該項目的REAUTE/文檔，以下是其關鍵模塊/功能點：
| 模塊/功能 | 功能/描述 |
|---|---|
| 多帳戶管理 | 您可以在後台添加Claude / Gemini / OpenAI等多個帳戶，讓中繼服務輪換或智能選擇這些帳戶 |
| API密鑰管理 | 向消費者（客戶端）發放中繼級別的API密鑰，並使用該密鑰訪問中繼服務。中繼接收到請求後，使用後台帳號實際調用AI服務。 |
| 訪問控制/當前限制/並發控制 | 您可以為每個消費者的密鑰設置訪問速率、令牌限制和並發數，以控制濫用。 |
| 智能切換/故障容忍 | 當後台帳戶不可用（例如被禁止、過期或API錯誤等）時，中繼可以自動切換到另一個可用帳戶以繼續服務。 |
| 性能優化/連接池/緩存 | 減少延遲並提高吞吐量。文檔提到「連接池、緩存」作為性能優化的一種手段。 |
| 監控/使用統計數據 | 在Web界面上顯示每個帳戶/用戶的代幣使用情況、消費費用、響應表現等指標。 |
| 安全控制 | 包括訪問限制、速率控制、客戶端限制（用戶代理白名單/限制哪些客戶端可用）等。 |
| 代理/網絡支持 | 支持HTTP /SOCKS 5代理繞過網絡限制或訪問後台服務。 |
| 多種服務兼容/路由分布 | 根據不同的路徑識別請求的服務類型（例如 /克勞德/,/機器人/克勞德//openai//雙子座/ 等等）並轉發到相應類型的帳戶池。（[GitHub][1]） |
| 前端界面/管理後端 | 提供Web管理頁面，供管理員添加帳戶、創建API密鑰、查看統計數據、調整設置等。 |
| 部署方式多種多樣 | 支持一鍵部署腳本、Docker/docker-compose、反向代理（Caddy/Nginx）等。 |
3.使用場景/適合人群
來自REAUTE的「這個項目適合您嗎？「在那篇文章中，作者明確提到以下類型的人可能會使用這個項目：
- 地區受限制/難以訪問Claude服務。
- 想要通過多個帳戶拼車的用戶。
- 他們擔心第三方圖像/公共中繼泄露對話內容，並希望控制中繼節點。
- 具有一定的技術基礎，願意自行維護和部署中繼服務。
- 需要穩定、長期地接觸克勞德，並且不願意依賴公共鏡像的不穩定性。
也就是說，該項目主要針對那些：
- 我希望建立一個代理/中繼層來集中管理人工智慧服務。
- 需要多個帳戶或多人共享帳戶池;
- 我想控制訪問權限、權限和成本;
- 具有一定的運營和維護能力，希望自己部署、監控、容忍故障。
4.優勢/受益
這種中繼/中繼設計具有一些明顯的優點：
- 安全隱私控制
用戶對話不會直接暴露給公共鏡像網站或第三方服務提供商，而僅通過您自己的中繼節點進行。 - 分攤成本/多帳戶池
多人可以共享帳戶池，中繼將幫助您分配和切換負載，使其更具成本效益。 - 統一入口+兼容多個後台
前端調用您部署的中繼服務，而不必管理多個不同服務的接口、地址和身份驗證方法等兼容性問題。 - 控制能力
您可以針對不同的用戶和密鑰進行訪問控制、限流、監控、使用統計等。 - 穩定性/異常恢復
如果後台帳戶發生異常，中繼可以自動刪除或切換到替代帳戶，以降低服務中斷的風險。 - 運營維護自主控制
您可以查看和管理所有中繼級別的日誌、狀態、性能指標等，而無需依賴公共服務提供商的透明度。
5.風險、挑戰和限制
雖然該項目功能豐富，但仍有一些風險/限制需要注意或可能包括：
- 違反服務條款的風險
REAUTE中有一條警告：「使用此物品可能違反Anthropic的服務條款。「與使用此項目相關的所有風險均由用戶自行承擔。”
換句話說，官方用戶協議或服務條款中可能不允許這種中轉/拼車/轉發的方式。 - 帳戶禁令/降級
如果多個用戶共享一個帳戶池，如果有一個用戶違反規則，就有帳戶被封禁/降級的風險，這會影響到所有人。 - 中繼性能瓶頸/延遲
儘管有連接池和緩存優化，但中繼本身仍然是一個額外的網絡跳躍點，可能會引入延遲或吞吐量瓶頸。 - 運維成本
雖然最低配置不高（1核、512 MB、30 GB硬碟等），需要確保穩定性、高可用性、數據備份、監控、異常恢復、升級回滾等運營維護工作。 - 網絡訪問/本地限制
網絡條件、跨境連結以及從國內攔截Anthropic / Claude訪問的可能性可能會影響服務質量。該文件還提到，Cloudflare可能會阻止一些雲供應商/線路的訪問。 - 安全/加密風險
儘管中繼可以進行API密鑰管理、加密和訪問控制，但如果部署不當且密鑰管理不嚴格，也可能成為新的攻擊面。 - 同步/版本兼容
API協議、版本更改和後台服務的認證方法更新（Claude、OpenAI、Gemini等）可能導致中繼及時與更新兼容。
6.技術細節/核心設計點（高級）
雖然我還沒有進行逐行代碼調試，但根據文檔和項目結構，我可以猜測核心設計思想如下：
- 路由和路徑識別
中繼根據請求的路徑前置碼確定正在呼叫哪種類型的服務（例如/克勞德/,/機器人/./openai//雙子座/等），並選擇相應的帳戶池進行轉發。 - 請求封裝轉換
前端請求發送給中繼後，中繼會根據後台服務的需求重新封裝請求（可能是SON主體轉換、頭部調整、認證令牌注入等），然後將其轉發到後台服務。 - 身份驗證/ API密鑰驗證
消費者向中繼站提出的請求必須附有中繼站發出的API Key。在允許訪問和轉發到後台之前，中繼首先驗證此密鑰。Relays還可以查看密鑰的權限配置（速率限制、並發數、可訪問模型等）限制請求。 - 有效負載/投票/切換政策
當多個後台帳戶可用時，中繼決定如何分配請求：民意調查、加權、優先級、負載平衡、錯誤再試等。如果帳戶出錯、中斷或禁止，則應刪除中繼或切換到下一個帳戶。 - 監控/統計模塊
中繼記錄每個密鑰/帳戶的令牌消耗、請求數量、錯誤率、延遲等指標，並在管理界面上顯示這些數據。 - 緩存/連接池/優化
您可以緩存部分響應、重複使用HTTFTKeep-Alive連接、管理連接池並減少頻繁建立連接的負擔。 - 後台管理界面+前端SPA
該項目包括用於操作帳戶、密鑰、監控等的管理前端界面（管理員SPA）。後台為該界面提供API支持。 - 配置/環境/部署
. inf、配置文件、Docker/docker-compose部署方法、反向代理（Caddy/Nginx）訪問等。
7.如何使用/部署流程（高級概述）
假設您想自己構建此中繼服務，以下是典型流程（根據REAUTE）：
- 環境準備：Linux伺服器，安裝Node.js 18+，Redis。
- 克隆代碼、配置
. inf和。& nbsp;config - 安裝依賴項（
npm install），建設前端（nPM運行構建：網絡). - 初始化管理員帳戶（
nPM運行設置). - 啟動服務（守護進程/後台運行模式）（
nPM運行服務：開始：守護進程). - 打開管理界面（瀏覽器訪問
http：//伺服器：3000/web）並登錄管理員。 - 添加後台帳戶（Claude、OpenAI、Gemini等）在後台完成OAuth授權/密鑰配置。
- 在後台為消費者創建API Key並為其配置訪問權限（速率、並發性、模型限制等）。
- 外部客戶端/前端或工具僅使用獲得的API Key訪問中繼服務的API端點（而不是直接調用Claude / OpenAI）。
- 根據路由、密鑰權限和帳戶池對中繼進行轉發、監控和計數。
部署通常使用反向代理（例如Nginx/Caddy）來添加HTTPS/SSL、域名綁定、日誌記錄和安全控制。
8.總結/它對你有用嗎？
這個項目是一個有趣的「人工智慧服務中繼/帳戶池管理」工具。對於那些想要自己管理人工智慧訪問、不想完全依賴公共圖像、想要以統一的方式安排多個帳戶以及想要監控/控制訪問行為的人來說，它很有價值。但它不是一個「即可安裝、零風險」的解決方案：它涉及運營管理、安全和合規風險。
[the_ad id=「6167」]Github：https://github.com/Wei-Shaw/claude-relay-service
管材：