pip install のタイムアウトを Clash で直す：PyPI と files.pythonhosted.org を分流（2026）

1. pip が伸ばすホスト：インデックスとバイナリは別ドメイン

多くの利用者は 「PyPI に繋がっていれば pip は動く」と捉えがちですが、実装の上ではJSON API や Simple API のホストと、実際の tarball／wheel を配る CDN 側が分かれています。典型例は pypi.org 系と files.pythonhosted.org の組み合わせで、どちらか一方だけが遅い・遮断されていると、解決済みに見えてダウンロード bar が進まない挙動になります。リダイレクトや歴史的な pypi.io などを挟む経路もあるため、失敗ログに出たホスト名をそのままルールに足す運用が現実的です。

コンテナ内からホストの Clash を見に行く構成は Docker をホスト Clash 経由にする記事と住み分けできます。Node 系の registry／tarball 分流は Windows の npm／pnpm と Clash の記事と思考の骨架がほぼ同じで、本稿は Python にフォーカスします。購読やルールの入口は サブスクリプションの取り込みと ルールルーティングを併読すると理解が速くなります。

2. ターミナル側：HTTP_PROXY と pip の出口を一本化

macOS・Linux・Windows いずれでも、まずはpip が動くシェルに HTTP_PROXY と HTTPS_PROXY を明示します。形式は http://127.0.0.1:7890 のように Clash が応答する HTTP プロキシを指します（ポートは環境に合わせて読み替え）。システムプロキシだけオンにしても、Python が参照しないターミナルは多いので、開発用シェルでは環境変数を前提にしたほうが確実です。

pip.conf（Linux や macOS ではユーザ領域、Windows では %APPDATA%\pip\pip.ini 等）に proxy を書く方法もありますが、環境変数と二重指定になると挙動が読みづらくなるので、どちらかに寄せるのが無難です。CI や仮想環境を跨ぐ場合は、変数の継承が切れていないかも忘れずに確認してください。

# Example: POSIX shell — adjust port
export HTTP_PROXY=http://127.0.0.1:7890
export HTTPS_PROXY=http://127.0.0.1:7890

Python 3.11 以降は certifi に加えて OS の truststore を参照する経路も整いつつありますが、企業プロキシの TLS インスペクションがある環境では、ルート CA がコンテナや仮想環境に伝播していないケースで失敗します。Clash 単体のルール調整だけでは直らないパターンなので、証明書エラーと単純なタイムアウトを分けてログに書く癖を付けると早いです。

3. Clash 分流：pypi.org／files.pythonhosted.org／pypi.io

環境変数ですべての TCP を Clash に入れたうえで、rules の前半で PyPI 関連ドメインを明示します。策略名 PROXY_GROUP は自分の proxy-groups に合わせて置き換えてください。要点は files.pythonhosted.org を必ず同じグループへ送ることです。広い GEOIP や緩い DOMAIN-SUFFIX だけに頼ると、意図しない経路に落ちて帯域が細ることがあります。

# Mihomo / Clash Meta style — illustrative only
rules:
  - DOMAIN,pypi.org,PROXY_GROUP
  - DOMAIN,files.pythonhosted.org,PROXY_GROUP
  - DOMAIN-SUFFIX,pythonhosted.org,PROXY_GROUP
  - DOMAIN,pypi.io,PROXY_GROUP

購読ルールが頻繁に更新される構成では、カスタム行が追い越される位置に置かれていないかを確認します。rule-providers に退避させる前でも、まずは 十数行の DOMAIN 足場で挙動を安定させ、ログで伸びているホストをproviderへ昇格させると安全です。帯域の細いノードを選び続けると wheel が大きいパッケージで再開が効かなくなるため、PyPI 用の策略はレイテンシよりも切断耐性を優先する判断もあります。

4. DNS と fake-ip：名前と策略がズレるとき

mihomo 系で fake-ip を使うと、アプリが見る IP とルール評価で使うドメイン情報の対応がずれるとタイムアウトが消えないことがあります。HTTPS トラフィックでは SNI を Sniffer で復元してルールへ載せる、あるいは該当ドメインだけ redir-host 寄りの扱いに寄せる、といった調整が教科書的な対処です。詳しい比較は fake-ip と redir-host の routing 修正記事が近いテーマです。

Windows でブラウザの DoH だけが別リゾルバを見ていると、curl とブラウザで到達性が一致しないこともあります。pip は基本的に OS のスタック側に近いので、Windows の安全な DNS とシステム代理の整理記事と併せて、名前解決の単一の物語にそろえると再現性が上がります。

5. 国内ミラーと併用するときの NO_PROXY

清華や阿里系などのミラーを --index-url で指している場合でも、メタデータとファイル配信のホストが分かれるケースは残ります。ミラー全体を NO_PROXY に入れ、Clash 側でも DOMAIN-SUFFIX で DIRECT に固定すると、海外ノードへ無駄に迂回するのを防げます。逆に公式 PyPI に戻す場面では、ミラー用の例外を外し忘れると奇妙な混線が起きるので、シェルプロファイルでプロファイルを分けると安全です。

社内の devpi や Artifactory を PIP_INDEX_URL にしているなら、その FQDN も NO_PROXY と DIRECT ルールの両方に含めるのが定石です。wheel の実体が社外のキャッシュにリダイレクトされるポリシーなら、ログに出た外部ホストを同じ運用でルール追加してください。

6. ログとコマンドで切り分け

まず curl -v -x http://127.0.0.1:7890 https://pypi.org/simple/pip/ のように、プロキシ経由でインデックスが読めるかを確認します。続けて files.pythonhosted.org 上の実 URL を一つ拾って curl -I で応答を見ると、帯域・リダイレクト・認証のどこで詰まっているかが分かれます。pip 側は pip install -v パッケージ で どの URL を順に取りに行ったかが追いやすいです。

Clash の接続ログでは 策略名・chains・ホストの三点セットを見ます。タイムアウトばかりが増えるノードは、PyPI 向けグループから外すか、自動選択の滑らかさより手動の安定ノードを選ぶほうがトータルで速いことがあります。購読自体の TLS や DNS が不安定なら Windows の購読 TLS・DNS・ログ記事も参照ください。

# pip verbose example
python -m pip install -v requests

7. よくある質問

インデックスだけ成功してダウンロードで止まります。

files.pythonhosted.org が別策略や DIRECT に落ちていないか、ログのホスト名で確認してください。pip install -v に出る URL と Clash の接続表を突き合わせると早いです。

Linux コンテナ内の pip も同じルールで良いですか？

ネットワーク名前空間が分かれている場合、127.0.0.1 はコンテナ自身を指します。ホストの Clash に繋ぐなら docker host ゲートウェイや service 名を HTTP_PROXY に書き換えてください。詳細は Docker 向けの記事を参照してください。

wheel と sdist で差は出ますか？

sdist はソースアーカイブを引いたうえでローカルビルドが走ることがあり、取得時間とビルド時間の両方がネットワーク依存になります。可能なら事前に wheel のあるビルドタグを揃えると体感が安定しやすいです。

8. まとめ

pip のタイムアウト対策は、単に「プロキシをオン」では足りず、pypi.org と files.pythonhosted.org の両方を同じ出口とルールで扱うことが核心です。環境変数で Clash に集約し、DOMAIN 行で明示し、DNS とログで名前の食い違いを潰す、この三層がそろうと wheel／sdist の取得は再現性が高くなります。

開発者向けプロキシアプリは多いですが、更新が止まった GUI ラッパーや、ログが薄い汎用 VPN タイプでは、PyPI のようにホストが増え続けるワークフローに弱く、原因特定に時間が溶けます。ルールと接続ログを素直に読める mihomo 系クライアントでは、伸びたドメインをその日のうちに追記する運用が現実的で、長時間の pip install を抱えるチームほど差が出やすいです。

自分用のビルド選びとポート確認から始めるなら、 → 公式ページから無料で Clash をダウンロードし、分流とログを試す のが手早いでしょう。