1. なぜ今「API の揺れ」が話題になるのか
モデル本体の話題が「性能ベンチ」から「長時間エージェント」「ツール呼び出しの安定性」へ移ると、利用者の不満も自然とレイテンシの尾や接続の切れ方に寄ります。GLM-5.1 のようにウェイトやライセンス形態が開発者向けに開かれると、同時にコンソール・課金・トークン計測・実推論エンドポイントへ分散した HTTP が一気に増え、どれか一系統だけ意図しない経路に落ちていると、画面では「ずっと読み込み」、SDK では「タイムアウト」として現れます。
Clash 系クライアントの強みは、これらをホスト名単位で観察し、ルール分流としてPROXY か DIRECT に振り分けられる点にあります。本稿が扱うのは違法な迂回ではなく、契約とポリシーの範囲で自宅や検証用 VPC の出口を揃えるための一般的な話に限ります。
2. HTTP API とターミナル／社内網の境界
当サイトでは npm や Git がまだ直結しているときのように、パッケージレジストリや git clone を HTTPS_PROXY から本機の mixed-port に寄せる記事を別枠で用意しています。一方、本稿の主役は bigmodel や 智谱 が提供する推論・管理用の HTTPSであり、registry.npmjs.org や github.com とはドメイン空間がまったく別です。
したがって「ターミナル記事どおりに環境変数を入れたのに API だけ失敗する」場合は、まず curl が本当に open.bigmodel.cn など推論ホストへ向かっているか、接続ログで マッチしたルールを確認します。ルール分流は万能ではなく、アプリがプロキシを参照していないケースは別のレイヤーです。
3. 症状の見立て（TLS・429・ストリーム）
TLS Handshake Timeout や証明書警告は、しばしばノード品質や途中の HTTPS 検査、SNI と絡みます。詳細な切り分けは TLS 専用の記事に譲りつつ、Z.ai／智谱 利用時は「同じキーでもノードを変えると通る」のであれば、まずノード選択を固定して再現性を潰すのが得策です。
一方、HTTP 429 や明確な rate limit メッセージはプロバイダ側の制御である可能性が高く、Clash でどれだけ綺麗に振っても根本解決にはなりません。それでも出口 IP が頻繁に泳ぐと、プロバイダから見たスパイクが増え、体感として「不安定」に近づくことはあります。安定ノードに固定し、SDK 側に指数バックオフを入れる、の二段構えが現実的です。
| 症状 | まず疑う層 | Clash 側で試すこと |
|---|---|---|
| コンソールだけ白画面 | 静的 CDN や別サブドメインが DIRECT | ログの Server Name を列挙し DOMAIN-SUFFIX を追加 |
| SDK のみタイムアウト | 環境変数・プロキシ無視 | ターミナル記事どおり mixed-port へ寄せる |
| ノードを変えると直る | 輻輳・地理的ルーティング | 手動固定 → 問題なければ自動グループを調整 |
| 常に 429 | クォータ・レート制限 | 並列数を下げる（ルール以前の対策） |
4. 智谱・bigmodel・Z.ai のドメイン整理
公式側のホスト名はアップデートで増減するため、以下は設定時の思考用メモです。必ず手元のクライアントログに出た名前を正としてください。
- 国内向け開発者プラットフォーム：
bigmodel.cnやopen.bigmodel.cnなど、ドキュメント・キー発行・課金画面と API が分割されている構成が一般的です。 - ブランドドメイン：
zhipuai.cn／zhipuai.com系でポータルやリダイレクトがまとまっている場合があります。 - グローバルブランド Z.ai：
z.ai配下にマーケティング、ダッシュボード、推論エンドポイントが載るケース。実際のホストはサブドメインで分かれます。 - CDN・テレメトリ：チャット UI が別ホストからチャンクを取ると、見た目は単一ページでも背後は複数ドメインです。
ChatGPT／Gemini 記事との関係
当サイトの ChatGPT 向け記事や Gemini 向け記事は、それぞれ openai.com や google 系にフォーカスしており、本稿の 智谱／bigmodel とはルール集合が重なりません。既に AI 向けの長い RULE-SET を入れている場合でも、漏れたホストが DIRECT に落ちると今回の症状になり得るため、短い追記ルールを上位に置く運用が有効です。
5. Clash ルール例（コピー用）
Clash（Mihomo／Meta 系）では rules: を上から評価するため、具体ドメインを先に、広い国別ルールを後ろへ、が基本形です。
# Example only — verify hostnames in your client logs
rules:
- DOMAIN-SUFFIX,bigmodel.cn,PROXY
- DOMAIN-SUFFIX,zhipuai.cn,PROXY
- DOMAIN-SUFFIX,zhipuai.com,PROXY
- DOMAIN-SUFFIX,z.ai,PROXY
- MATCH,DIRECTログに maas や計測用の別ドメインが出たら、その行を足し、出なければ削って構いません。DOMAIN-KEYWORD,zhipu のような広い書き方は衝突しやすいので避けます。全体像は ドキュメント概要も参照してください。
6. ノード固定とレート制限の切り分け
ノード選択は ping だけでは足りません。特に長いストリーミングでは、BGP の揺れや輻輳で中盤で切れることがあります。実務では、同一プロファイルで手動の単一ノードに固定し、コンソールと API の両方を試してから、自動フェイルオーバーへ戻すのが安全です。
智谱 の API はビジネス契約やリージョン設定によって挙動が変わるため、本稿では契約内容には踏み込みませんが、固定出口 IP が推奨されるプランであれば、ノードより上流の専用線／固定 VPSの話になる点だけ留意してください。
7. 企業内網・DIRECT を壊さない書き方
会社支給機では 10.0.0.0/8 などを DIRECT にしておくルールが先にあります。bigmodel 向けの DOMAIN-SUFFIX を足しても、社内 Git や監視ダッシュボードには触れないのが理想です。逆に「検証のために全部 PROXY」と雑に書くと、社内 Only のホストまで巻き込む事故が起きます。
境界の切り方としては、① 社内プレフィックスは従来どおり DIRECT 優先、② 智谱／Z.ai の列挙だけを PROXY に逃がす、の二層が読みやすく、レビューもしやすいです。
8. DNS・fake-ip・ログの読み方
fake-ip 有効時は、ブラウザの開発者ツールに出る名前と、コア内部の解決結果が一致しないように見えることがあります。fake-ip と DNS の切り分け記事と併読し、漏れない DNS と ルールの整合を先に揃えます。
ログでは matched rule と chosen proxy の組が重要です。期待と違うときは、より上にある RULE-SET が先に吸っていないか、DOMAIN-SUFFIX の綴りが実ホストと一致しているかを確認してください。
9. セルフチェック
- クライアント更新：GUI とコアの版がずれるとログ形式も変わります。公式ダウンロードページから現行版へ。
- プロキシ経路の統一：システムプロキシと TUN のどちらに載せるかを決め、例外アプリを洗い出す。
- ルール命中：コンソールと API で Server Name が揃って PROXY になっているか。
- ノード：別ノードで再現するか。
- DNS：解決経路と fake-ip の矛盾がないか。
- 429／401：キー・クォータ・エンドポイント URL の打ち間違い（ネット以前）。
10. まとめ
Z.ai と 智谱 の GLM-5.1 を、コンソールと API の両方から使うとき、通信は単一ドメインに収まりません。bigmodel.cn や z.ai などをログで正にし、Clash のルール分流で PROXY に揃え、ノード選択と DNS をセットで見直すと、握手失敗や出口のブレによる擬似的な不安定さを大きく減らせます。ターミナルのレジストリや社内システムとはドメインが別だと心得ておくと、設定の衝突も防げます。
ログが読みやすいプロキシツールは試行錯誤のコストを下げます。ルールを短く足すだけで、夜間のバッチやエージェント実行が途切れにくくなることも珍しくありません。