github/cc-switch
1
0
Fork 0
mirror of https://github.com/farion1231/cc-switch.git synced 2026-05-22 21:50:44 +08:00
Code Issues Packages Projects Releases Wiki Activity

docs: rename takeover docs to routing across all languages

Browse Source 
Rename 4.2-takeover.md to 4.2-routing.md in zh/en/ja user manuals,
replacing all "接管/takeover" terminology with "路由/routing" to match
the rebranded feature name. Update README index links accordingly.
This commit is contained in:
Jason
2026-04-14 15:15:39 +08:00
parent 7ec92c32a5
commit 989c445828
9 changed files with 588 additions and 588 deletions
Download Patch File Download Diff File Expand all files Collapse all files
docs/user-manual/en/4-proxy/4.2-routing.md
+195
View File
@@ -0,0 +1,195 @@
# 4.2 App Routing
## Overview
App routing means letting CC Switch route a specific application's API requests through the local routing service.
When routing is enabled:
- The app's API requests are forwarded through local routing
- Request logs and usage statistics can be recorded
- Failover functionality becomes available
## Prerequisites
The routing service must be started before using the app routing feature.
## Enable Routing
### Location
Settings > Advanced > Routing Service > App Routing area
### Steps
1. Ensure the routing service is started
2. Find the "App Routing" area
3. Enable the toggle for the desired apps
### Routing Toggles
| Toggle | Effect |
|--------|--------|
| Claude Routing | Route Claude Code requests |
| Codex Routing | Route Codex requests |
| Gemini Routing | Route Gemini CLI requests |
Multiple app routings can be enabled simultaneously.
## How Routing Works
### Configuration Changes
When routing is enabled, CC Switch modifies the app's configuration file to point the API endpoint to the local routing service.
**Claude configuration change**:
```json
// Before routing
{
"env": {
"ANTHROPIC_BASE_URL": "https://api.anthropic.com"
}
}
// After routing
{
"env": {
"ANTHROPIC_BASE_URL": "http://127.0.0.1:15721"
}
}
```
**Codex configuration change**:
```toml
# Before routing
base_url = "https://api.openai.com/v1"
# After routing
base_url = "http://127.0.0.1:15721/v1"
```
**Gemini configuration change**:
```bash
# Before routing
GOOGLE_GEMINI_BASE_URL=https://generativelanguage.googleapis.com
# After routing
GOOGLE_GEMINI_BASE_URL=http://127.0.0.1:15721
```
### Request Forwarding
When the routing service receives a request:
1. Identifies the request source (Claude/Codex/Gemini)
2. Looks up the currently enabled provider for that app
3. Forwards the request to the provider's actual endpoint
4. Records the request log
5. Returns the response to the app
## Routing Status Indicators
### Main Interface Indicators
When routing is enabled, the main interface shows the following changes:
- **Routing logo color**: Changes from colorless to green
- **Provider cards**: The currently active provider shows a green border
### Provider Card States
| State | Border Color | Description |
|-------|--------------|-------------|
| Currently Active | Blue | Provider in the config file (non-routing mode) |
| Routing Active | Green | Provider actually used by routing |
| Normal | Default | Unused provider |
## Disable Routing
### Steps
1. Turn off the corresponding app's routing toggle in the routing panel
2. Or directly stop the routing service
### Configuration Restoration
When disabling routing, CC Switch will:
1. Restore the app configuration to its pre-routing state
2. Save current request logs
## Routing and Provider Switching
### Switching Providers in Routing Mode
When switching providers in routing mode:
1. Click the "Enable" button on a provider in the main interface
2. The routing service immediately uses the new provider to forward requests
3. **No need to restart the CLI tool**
This is a major advantage of routing mode: provider switching takes effect instantly.
### Switching Without Routing
When switching providers without routing:
1. Configuration file is modified
2. CLI tool must be restarted for changes to take effect
## Multi-app Routing
Multiple apps can be routed simultaneously, each managed independently:
- Independent provider configurations
- Independent failover queues
- Independent request statistics
## Use Cases
### Scenario 1: Usage Monitoring
Enable routing + log recording to monitor API usage.
### Scenario 2: Quick Switching
With routing enabled, switching providers does not require restarting CLI tools.
### Scenario 3: Failover
Enabling routing is a prerequisite for using the failover feature.
## Notes
### Performance Impact
Routing adds minimal latency (typically < 10ms), negligible for most scenarios.
### Network Requirements
In routing mode, CLI tools must be able to access the local routing address.
### Configuration Backup
Before enabling routing, CC Switch backs up the original configuration and restores it when disabled.
## FAQ
### Requests Fail After Enabling Routing
Check:
- Is the routing service running normally
- Is the provider configuration correct
- Is the network working properly
### Configuration Not Restored After Disabling Routing
Possible causes:
- Routing service exited abnormally
- Configuration file was modified by another program
Solutions:
- Manually edit the provider and re-save
- Or re-enable and then disable routing
docs/user-manual/en/4-proxy/4.2-takeover.md
-195
View File
@@ -1,195 +0,0 @@
# 4.2 App Takeover
## Overview
App takeover means letting CC Switch's proxy intercept and forward a specific application's API requests.
When takeover is enabled:
- The app's API requests are forwarded through the local proxy
- Request logs and usage statistics can be recorded
- Failover functionality becomes available
## Prerequisites
The proxy service must be started before using the app takeover feature.
## Enable Takeover
### Location
Settings > Advanced > Proxy Service > App Takeover area
### Steps
1. Ensure the proxy service is started
2. Find the "App Takeover" area
3. Enable the toggle for the desired apps
### Takeover Toggles
| Toggle | Effect |
|--------|--------|
| Claude Takeover | Intercept Claude Code requests |
| Codex Takeover | Intercept Codex requests |
| Gemini Takeover | Intercept Gemini CLI requests |
Multiple app takeovers can be enabled simultaneously.
## How Takeover Works
### Configuration Changes
When takeover is enabled, CC Switch modifies the app's configuration file to point the API endpoint to the local proxy.
**Claude configuration change**:
```json
// Before takeover
{
"env": {
"ANTHROPIC_BASE_URL": "https://api.anthropic.com"
}
}
// After takeover
{
"env": {
"ANTHROPIC_BASE_URL": "http://127.0.0.1:15721"
}
}
```
**Codex configuration change**:
```toml
# Before takeover
base_url = "https://api.openai.com/v1"
# After takeover
base_url = "http://127.0.0.1:15721/v1"
```
**Gemini configuration change**:
```bash
# Before takeover
GOOGLE_GEMINI_BASE_URL=https://generativelanguage.googleapis.com
# After takeover
GOOGLE_GEMINI_BASE_URL=http://127.0.0.1:15721
```
### Request Forwarding
When the proxy receives a request:
1. Identifies the request source (Claude/Codex/Gemini)
2. Looks up the currently enabled provider for that app
3. Forwards the request to the provider's actual endpoint
4. Records the request log
5. Returns the response to the app
## Takeover Status Indicators
### Main Interface Indicators
When takeover is enabled, the main interface shows the following changes:
- **Proxy logo color**: Changes from colorless to green
- **Provider cards**: The currently active provider shows a green border
### Provider Card States
| State | Border Color | Description |
|-------|--------------|-------------|
| Currently Active | Blue | Provider in the config file (non-proxy mode) |
| Proxy Active | Green | Provider actually used by the proxy |
| Normal | Default | Unused provider |
## Disable Takeover
### Steps
1. Turn off the corresponding app's takeover toggle in the proxy panel
2. Or directly stop the proxy service
### Configuration Restoration
When disabling takeover, CC Switch will:
1. Restore the app configuration to its pre-takeover state
2. Save current request logs
## Takeover and Provider Switching
### Switching Providers in Takeover Mode
When switching providers in takeover mode:
1. Click the "Enable" button on a provider in the main interface
2. The proxy immediately uses the new provider to forward requests
3. **No need to restart the CLI tool**
This is a major advantage of takeover mode: provider switching takes effect instantly.
### Switching Without Takeover
When switching providers without takeover:
1. Configuration file is modified
2. CLI tool must be restarted for changes to take effect
## Multi-app Takeover
Multiple apps can be taken over simultaneously, each managed independently:
- Independent provider configurations
- Independent failover queues
- Independent request statistics
## Use Cases
### Scenario 1: Usage Monitoring
Enable takeover + log recording to monitor API usage.
### Scenario 2: Quick Switching
With takeover enabled, switching providers does not require restarting CLI tools.
### Scenario 3: Failover
Enabling takeover is a prerequisite for using the failover feature.
## Notes
### Performance Impact
The proxy adds minimal latency (typically < 10ms), negligible for most scenarios.
### Network Requirements
In takeover mode, CLI tools must be able to access the local proxy address.
### Configuration Backup
Before enabling takeover, CC Switch backs up the original configuration and restores it when disabled.
## FAQ
### Requests Fail After Takeover
Check:
- Is the proxy service running normally
- Is the provider configuration correct
- Is the network working properly
### Configuration Not Restored After Disabling Takeover
Possible causes:
- Proxy exited abnormally
- Configuration file was modified by another program
Solutions:
- Manually edit the provider and re-save
- Or re-enable and then disable takeover
docs/user-manual/en/README.md
+1 -1
View File
@@ -79,7 +79,7 @@ CC Switch User Manual
| File | Description |
|------|-------------|
| [4.1-service.md](./4-proxy/4.1-service.md) | Start proxy, configuration, running status |
| [4.2-takeover.md](./4-proxy/4.2-takeover.md) | App takeover, configuration changes, status indicators |
| [4.2-routing.md](./4-proxy/4.2-routing.md) | App routing, configuration changes, status indicators |
| [4.3-failover.md](./4-proxy/4.3-failover.md) | Failover queue, circuit breaker, health status |
| [4.4-usage.md](./4-proxy/4.4-usage.md) | Usage statistics, trend charts, pricing configuration |
| [4.5-model-test.md](./4-proxy/4.5-model-test.md) | Model test, health check, latency testing |
docs/user-manual/ja/4-proxy/4.2-routing.md
+195
View File
@@ -0,0 +1,195 @@
# 4.2 アプリケーションルーティング
## 機能説明
アプリケーションルーティングとは、CC Switch のルーティングサービスが特定アプリの API リクエストをルーティングすることです。
ルーティングを有効にすると：
- アプリの API リクエストがローカルルーティング経由で転送される
- リクエストログと使用量の統計を記録できる
- フェイルオーバー機能を使用できる
## 前提条件
アプリケーションルーティング機能を使用する前に、ルーティングサービスを起動する必要があります。
## ルーティングの有効化
### 操作場所
設定 → 詳細 → ルーティングサービス → アプリケーションルーティングエリア
### 操作手順
1. ルーティングサービスが起動していることを確認
2. 「アプリケーションルーティング」エリアを見つける
3. 必要なアプリのスイッチをオンにする
### ルーティングスイッチ
| スイッチ | 作用 |
|------|------|
| Claude ルーティング | Claude Code のリクエストをルーティング |
| Codex ルーティング | Codex のリクエストをルーティング |
| Gemini ルーティング | Gemini CLI のリクエストをルーティング |
複数のアプリのルーティングを同時に有効にできます。
## ルーティングの仕組み
### 設定の変更
ルーティングを有効にすると、CC Switch はアプリの設定ファイルを変更し、API エンドポイントをローカルルーティングに向けます。
**Claude 設定の変更**：
```json
// ルーティング前
{
"env": {
"ANTHROPIC_BASE_URL": "https://api.anthropic.com"
}
}
// ルーティング後
{
"env": {
"ANTHROPIC_BASE_URL": "http://127.0.0.1:15721"
}
}
```
**Codex 設定の変更**：
```toml
# ルーティング前
base_url = "https://api.openai.com/v1"
# ルーティング後
base_url = "http://127.0.0.1:15721/v1"
```
**Gemini 設定の変更**：
```bash
# ルーティング前
GOOGLE_GEMINI_BASE_URL=https://generativelanguage.googleapis.com
# ルーティング後
GOOGLE_GEMINI_BASE_URL=http://127.0.0.1:15721
```
### リクエストの転送
ルーティングサービスがリクエストを受信すると：
1. リクエスト元を識別（Claude/Codex/Gemini）
2. そのアプリで現在有効なプロバイダーを検索
3. プロバイダーの実際のエンドポイントにリクエストを転送
4. リクエストログを記録
5. アプリにレスポンスを返却
## ルーティングステータスの表示
### メイン画面の表示
ルーティングを有効にすると、メイン画面に以下の変化があります：
- **ルーティング Logo の色**：無色から緑に変化
- **プロバイダーカード**：現在アクティブなプロバイダーに緑の枠が表示
### プロバイダーカードの状態
| 状態 | 枠の色 | 説明 |
|------|----------|------|
| 現在有効 | 青 | 設定ファイル内のプロバイダー（非ルーティングモード） |
| ルーティングアクティブ | 緑 | ルーティングが実際に使用しているプロバイダー |
| 通常 | デフォルト | 使用されていないプロバイダー |
## ルーティングの無効化
### 操作手順
1. ルーティングパネルで対応するアプリのルーティングスイッチをオフにする
2. またはルーティングサービスを直接停止
### 設定の復元
ルーティングを無効にすると、CC Switch は以下を実行します：
1. アプリの設定をルーティング前の状態に復元
2. 現在のリクエストログを保存
## ルーティングとプロバイダーの切り替え
### ルーティングモードでのプロバイダー切り替え
ルーティングモードでプロバイダーを切り替える場合：
1. メイン画面でプロバイダーの「有効化」ボタンをクリック
2. ルーティングサービスが新しいプロバイダーを使用してリクエストを即座に転送
3. **CLI ツールの再起動は不要**
これがルーティングモードの大きなメリットです：プロバイダーの切り替えが即座に反映されます。
### 非ルーティングモードでのプロバイダー切り替え
非ルーティングモードでプロバイダーを切り替える場合：
1. 設定ファイルを変更
2. CLI ツールの再起動が必要
## 複数アプリのルーティング
複数のアプリを同時にルーティングでき、それぞれ独立して管理されます：
- 独立したプロバイダー設定
- 独立したフェイルオーバーキュー
- 独立したリクエスト統計
## 使用シーン
### シーン 1：使用量の監視
ルーティング + ログ記録を有効にして、API の使用状況を監視します。
### シーン 2：素早い切り替え
ルーティングを有効にすると、プロバイダーの切り替えに CLI ツールの再起動が不要になります。
### シーン 3：フェイルオーバー
ルーティングの有効化はフェイルオーバー機能を使用するための前提条件です。
## 注意事項
### パフォーマンスへの影響
ルーティングにより少量のレイテンシ（通常 < 10ms）が追加されますが、ほとんどのシーンでは無視できます。
### ネットワーク要件
ルーティングモードでは、CLI ツールがローカルルーティングアドレスにアクセスできる必要があります。
### 設定のバックアップ
ルーティングを有効にする前に、CC Switch は元の設定をバックアップし、無効化時に復元します。
## よくある質問
### ルーティング後にリクエストが失敗する
確認事項：
- ルーティングサービスが正常に実行されているか
- プロバイダーの設定が正しいか
- ネットワークが正常か
### ルーティングを無効にしても設定が復元されない
考えられる原因：
- ルーティングサービスの異常終了
- 設定ファイルが他のプログラムに変更された
解決方法：
- プロバイダーを手動で編集して保存し直す
- または再度ルーティングを有効にしてから無効にする
docs/user-manual/ja/4-proxy/4.2-takeover.md
-195
View File
@@ -1,195 +0,0 @@
# 4.2 アプリケーション接管
## 機能説明
アプリケーション接管とは、CC Switch のプロキシが特定アプリの API リクエストを接管することです。
接管を有効にすると：
- アプリの API リクエストがローカルプロキシ経由で転送される
- リクエストログと使用量の統計を記録できる
- フェイルオーバー機能を使用できる
## 前提条件
アプリケーション接管機能を使用する前に、プロキシサービスを起動する必要があります。
## 接管の有効化
### 操作場所
設定 → 詳細 → プロキシサービス → アプリケーション接管エリア
### 操作手順
1. プロキシサービスが起動していることを確認
2. 「アプリケーション接管」エリアを見つける
3. 必要なアプリのスイッチをオンにする
### 接管スイッチ
| スイッチ | 作用 |
|------|------|
| Claude 接管 | Claude Code のリクエストを接管 |
| Codex 接管 | Codex のリクエストを接管 |
| Gemini 接管 | Gemini CLI のリクエストを接管 |
複数のアプリの接管を同時に有効にできます。
## 接管の仕組み
### 設定の変更
接管を有効にすると、CC Switch はアプリの設定ファイルを変更し、API エンドポイントをローカルプロキシに向けます。
**Claude 設定の変更**：
```json
// 接管前
{
"env": {
"ANTHROPIC_BASE_URL": "https://api.anthropic.com"
}
}
// 接管後
{
"env": {
"ANTHROPIC_BASE_URL": "http://127.0.0.1:15721"
}
}
```
**Codex 設定の変更**：
```toml
# 接管前
base_url = "https://api.openai.com/v1"
# 接管後
base_url = "http://127.0.0.1:15721/v1"
```
**Gemini 設定の変更**：
```bash
# 接管前
GOOGLE_GEMINI_BASE_URL=https://generativelanguage.googleapis.com
# 接管後
GOOGLE_GEMINI_BASE_URL=http://127.0.0.1:15721
```
### リクエストの転送
プロキシがリクエストを受信すると：
1. リクエスト元を識別（Claude/Codex/Gemini）
2. そのアプリで現在有効なプロバイダーを検索
3. プロバイダーの実際のエンドポイントにリクエストを転送
4. リクエストログを記録
5. アプリにレスポンスを返却
## 接管ステータスの表示
### メイン画面の表示
接管を有効にすると、メイン画面に以下の変化があります：
- **プロキシ Logo の色**：無色から緑に変化
- **プロバイダーカード**：現在アクティブなプロバイダーに緑の枠が表示
### プロバイダーカードの状態
| 状態 | 枠の色 | 説明 |
|------|----------|------|
| 現在有効 | 青 | 設定ファイル内のプロバイダー（非プロキシモード） |
| プロキシアクティブ | 緑 | プロキシが実際に使用しているプロバイダー |
| 通常 | デフォルト | 使用されていないプロバイダー |
## 接管の無効化
### 操作手順
1. プロキシパネルで対応するアプリの接管スイッチをオフにする
2. またはプロキシサービスを直接停止
### 設定の復元
接管を無効にすると、CC Switch は以下を実行します：
1. アプリの設定を接管前の状態に復元
2. 現在のリクエストログを保存
## 接管とプロバイダーの切り替え
### 接管モードでのプロバイダー切り替え
接管モードでプロバイダーを切り替える場合：
1. メイン画面でプロバイダーの「有効化」ボタンをクリック
2. プロキシが新しいプロバイダーを使用してリクエストを即座に転送
3. **CLI ツールの再起動は不要**
これが接管モードの大きなメリットです：プロバイダーの切り替えが即座に反映されます。
### 非接管モードでのプロバイダー切り替え
非接管モードでプロバイダーを切り替える場合：
1. 設定ファイルを変更
2. CLI ツールの再起動が必要
## 複数アプリの接管
複数のアプリを同時に接管でき、それぞれ独立して管理されます：
- 独立したプロバイダー設定
- 独立したフェイルオーバーキュー
- 独立したリクエスト統計
## 使用シーン
### シーン 1：使用量の監視
接管 + ログ記録を有効にして、API の使用状況を監視します。
### シーン 2：素早い切り替え
接管を有効にすると、プロバイダーの切り替えに CLI ツールの再起動が不要になります。
### シーン 3：フェイルオーバー
接管の有効化はフェイルオーバー機能を使用するための前提条件です。
## 注意事項
### パフォーマンスへの影響
プロキシにより少量のレイテンシ（通常 < 10ms）が追加されますが、ほとんどのシーンでは無視できます。
### ネットワーク要件
接管モードでは、CLI ツールがローカルプロキシアドレスにアクセスできる必要があります。
### 設定のバックアップ
接管を有効にする前に、CC Switch は元の設定をバックアップし、無効化時に復元します。
## よくある質問
### 接管後にリクエストが失敗する
確認事項：
- プロキシサービスが正常に実行されているか
- プロバイダーの設定が正しいか
- ネットワークが正常か
### 接管を無効にしても設定が復元されない
考えられる原因：
- プロキシの異常終了
- 設定ファイルが他のプログラムに変更された
解決方法：
- プロバイダーを手動で編集して保存し直す
- または接管を再度有効にしてから無効にする
docs/user-manual/ja/README.md
+1 -1
View File
@@ -79,7 +79,7 @@ CC Switch ユーザーマニュアル
| ファイル | 内容 |
|------|------|
| [4.1-service.md](./4-proxy/4.1-service.md) | プロキシの起動、設定項目、実行状態 |
| [4.2-takeover.md](./4-proxy/4.2-takeover.md) | アプリケーション接管、設定変更、ステータス表示 |
| [4.2-routing.md](./4-proxy/4.2-routing.md) | アプリケーションルーティング、設定変更、ステータス表示 |
| [4.3-failover.md](./4-proxy/4.3-failover.md) | フェイルオーバーキュー、サーキットブレーカー、ヘルスステータス |
| [4.4-usage.md](./4-proxy/4.4-usage.md) | 使用量統計、トレンドグラフ、料金設定 |
| [4.5-model-test.md](./4-proxy/4.5-model-test.md) | モデルテスト、ヘルスチェック、レイテンシテスト |
docs/user-manual/zh/4-proxy/4.2-routing.md
+195
View File
@@ -0,0 +1,195 @@
# 4.2 应用路由
## 功能说明
应用路由是指让 CC Switch 路由特定应用的 API 请求。
开启路由后：
- 应用的 API 请求会通过本地路由转发
- 可以记录请求日志和统计用量
- 可以使用故障转移功能
## 前提条件
使用应用路由功能前，需要先启动路由服务。
## 开启路由
### 操作位置
设置 → 高级 → 路由服务 → 应用路由区域
### 操作步骤
1. 确保路由服务已启动
2. 找到「应用路由」区域
3. 为需要的应用开启开关
### 路由开关
| 开关 | 作用 |
|------|------|
| Claude 路由 | 路由 Claude Code 的请求 |
| Codex 路由 | 路由 Codex 的请求 |
| Gemini 路由 | 路由 Gemini CLI 的请求 |
可以同时开启多个应用的路由。
## 路由原理
### 配置修改
开启路由后，CC Switch 会修改应用的配置文件，将 API 端点指向本地路由。
**Claude 配置变更**：
```json
// 路由前
{
"env": {
"ANTHROPIC_BASE_URL": "https://api.anthropic.com"
}
}
// 路由后
{
"env": {
"ANTHROPIC_BASE_URL": "http://127.0.0.1:15721"
}
}
```
**Codex 配置变更**：
```toml
# 路由前
base_url = "https://api.openai.com/v1"
# 路由后
base_url = "http://127.0.0.1:15721/v1"
```
**Gemini 配置变更**：
```bash
# 路由前
GOOGLE_GEMINI_BASE_URL=https://generativelanguage.googleapis.com
# 路由后
GOOGLE_GEMINI_BASE_URL=http://127.0.0.1:15721
```
### 请求转发
路由收到请求后：
1. 识别请求来源（Claude/Codex/Gemini）
2. 查找该应用当前启用的供应商
3. 将请求转发到供应商的实际端点
4. 记录请求日志
5. 返回响应给应用
## 路由状态指示
### 主界面指示
开启路由后，主界面会有以下变化：
- **路由 Logo 颜色**：从无色变为绿色
- **供应商卡片**：当前活跃的供应商显示绿色边框
### 供应商卡片状态
| 状态 | 边框颜色 | 说明 |
|------|----------|------|
| 当前启用 | 蓝色 | 配置文件中的供应商（非路由模式） |
| 路由活跃 | 绿色 | 路由实际使用的供应商 |
| 普通 | 默认 | 未使用的供应商 |
## 关闭路由
### 操作步骤
1. 在路由面板中关闭对应应用的路由开关
2. 或直接停止路由服务
### 配置恢复
关闭路由时，CC Switch 会：
1. 将应用配置恢复到路由前的状态
2. 保存当前的请求日志
## 路由与供应商切换
### 路由模式下切换供应商
在路由模式下切换供应商：
1. 在主界面点击供应商的「启用」按钮
2. 路由立即使用新供应商转发请求
3. **无需重启 CLI 工具**
这是路由模式的一大优势：切换供应商即时生效。
### 非路由模式下切换
在非路由模式下切换供应商：
1. 修改配置文件
2. 需要重启 CLI 工具才能生效
## 多应用路由
可以同时路由多个应用，每个应用独立管理：
- 独立的供应商配置
- 独立的故障转移队列
- 独立的请求统计
## 使用场景
### 场景一：用量监控
开启路由 + 日志记录，监控 API 使用情况。
### 场景二：快速切换
开启路由后，切换供应商无需重启 CLI 工具。
### 场景三：故障转移
开启路由是使用故障转移功能的前提。
## 注意事项
### 性能影响
路由会增加少量延迟（通常 < 10ms），对于大多数场景可以忽略。
### 网络要求
路由模式下，CLI 工具需要能够访问本地路由地址。
### 配置备份
开启路由前，CC Switch 会备份原始配置，关闭时恢复。
## 常见问题
### 路由后请求失败
检查：
- 路由服务是否正常运行
- 供应商配置是否正确
- 网络是否正常
### 关闭路由后配置未恢复
可能原因：
- 路由异常退出
- 配置文件被其他程序修改
解决方法：
- 手动编辑供应商，重新保存
- 或重新启用再关闭路由
docs/user-manual/zh/4-proxy/4.2-takeover.md
-195
View File
@@ -1,195 +0,0 @@
# 4.2 应用接管
## 功能说明
应用接管是指让 CC Switch 代理接管特定应用的 API 请求。
开启接管后：
- 应用的 API 请求会通过本地代理转发
- 可以记录请求日志和统计用量
- 可以使用故障转移功能
## 前提条件
使用应用接管功能前，需要先启动代理服务。
## 开启接管
### 操作位置
设置 → 高级 → 代理服务 → 应用接管区域
### 操作步骤
1. 确保代理服务已启动
2. 找到「应用接管」区域
3. 为需要的应用开启开关
### 接管开关
| 开关 | 作用 |
|------|------|
| Claude 接管 | 接管 Claude Code 的请求 |
| Codex 接管 | 接管 Codex 的请求 |
| Gemini 接管 | 接管 Gemini CLI 的请求 |
可以同时开启多个应用的接管。
## 接管原理
### 配置修改
开启接管后，CC Switch 会修改应用的配置文件，将 API 端点指向本地代理。
**Claude 配置变更**：
```json
// 接管前
{
"env": {
"ANTHROPIC_BASE_URL": "https://api.anthropic.com"
}
}
// 接管后
{
"env": {
"ANTHROPIC_BASE_URL": "http://127.0.0.1:15721"
}
}
```
**Codex 配置变更**：
```toml
# 接管前
base_url = "https://api.openai.com/v1"
# 接管后
base_url = "http://127.0.0.1:15721/v1"
```
**Gemini 配置变更**：
```bash
# 接管前
GOOGLE_GEMINI_BASE_URL=https://generativelanguage.googleapis.com
# 接管后
GOOGLE_GEMINI_BASE_URL=http://127.0.0.1:15721
```
### 请求转发
代理收到请求后：
1. 识别请求来源（Claude/Codex/Gemini）
2. 查找该应用当前启用的供应商
3. 将请求转发到供应商的实际端点
4. 记录请求日志
5. 返回响应给应用
## 接管状态指示
### 主界面指示
开启接管后，主界面会有以下变化：
- **代理 Logo 颜色**：从无色变为绿色
- **供应商卡片**：当前活跃的供应商显示绿色边框
### 供应商卡片状态
| 状态 | 边框颜色 | 说明 |
|------|----------|------|
| 当前启用 | 蓝色 | 配置文件中的供应商（非代理模式） |
| 代理活跃 | 绿色 | 代理实际使用的供应商 |
| 普通 | 默认 | 未使用的供应商 |
## 关闭接管
### 操作步骤
1. 在代理面板中关闭对应应用的接管开关
2. 或直接停止代理服务
### 配置恢复
关闭接管时，CC Switch 会：
1. 将应用配置恢复到接管前的状态
2. 保存当前的请求日志
## 接管与供应商切换
### 接管模式下切换供应商
在接管模式下切换供应商：
1. 在主界面点击供应商的「启用」按钮
2. 代理立即使用新供应商转发请求
3. **无需重启 CLI 工具**
这是接管模式的一大优势：切换供应商即时生效。
### 非接管模式下切换
在非接管模式下切换供应商：
1. 修改配置文件
2. 需要重启 CLI 工具才能生效
## 多应用接管
可以同时接管多个应用，每个应用独立管理：
- 独立的供应商配置
- 独立的故障转移队列
- 独立的请求统计
## 使用场景
### 场景一：用量监控
开启接管 + 日志记录，监控 API 使用情况。
### 场景二：快速切换
开启接管后，切换供应商无需重启 CLI 工具。
### 场景三：故障转移
开启接管是使用故障转移功能的前提。
## 注意事项
### 性能影响
代理会增加少量延迟（通常 < 10ms），对于大多数场景可以忽略。
### 网络要求
接管模式下，CLI 工具需要能够访问本地代理地址。
### 配置备份
开启接管前，CC Switch 会备份原始配置，关闭时恢复。
## 常见问题
### 接管后请求失败
检查：
- 代理服务是否正常运行
- 供应商配置是否正确
- 网络是否正常
### 关闭接管后配置未恢复
可能原因：
- 代理异常退出
- 配置文件被其他程序修改
解决方法：
- 手动编辑供应商，重新保存
- 或重新启用再关闭接管
docs/user-manual/zh/README.md
+1 -1
View File
@@ -79,7 +79,7 @@
| 文件 | 内容 |
|------|------|
| [4.1-service.md](./4-proxy/4.1-service.md) | 启动代理、配置项、运行状态 |
| [4.2-takeover.md](./4-proxy/4.2-takeover.md) | 应用接管、配置修改、状态指示 |
| [4.2-routing.md](./4-proxy/4.2-routing.md) | 应用路由、配置修改、状态指示 |
| [4.3-failover.md](./4-proxy/4.3-failover.md) | 故障转移队列、熔断器、健康状态 |
| [4.4-usage.md](./4-proxy/4.4-usage.md) | 用量统计、趋势图表、定价配置 |
| [4.5-model-test.md](./4-proxy/4.5-model-test.md) | 模型检查、健康检测、延迟测试 |