PyCharm のデバッガー接続をプロキシ経由にしない
選択した Python インタープリターを Proxychains 用にラップし、引数とデバッガーへの直接の loopback 経路を保ちます。
Python のデバッグ処理を Proxychains で包むと、2 種類の接続が捕捉され得ます。スクリプトの外向きサービス接続と、PyCharm へ戻るローカル接続です。デバッガーは後者がローカルに留まることを必要とします。
IDE とホストがインタープリターのラッパーに対応している場合は、プロジェクトの実際のインタープリターを指します:
#!/bin/sh
exec /usr/bin/proxychains4 -f /home/alex/proxychains-debug.conf "/home/alex/project/.venv/bin/python" "$@"実行ファイルの 2 つのパスと設定ファイルのパスを置き換えます。"$@" を転送すると IDE が渡す個々のデバッガー引数が保持されます。exec は起動したプロセスが IDE とその子プロセスの間に不要なラッパーシェルを残さないようにします。
その専用の Proxychains 設定では、意図したチェーンを保ち、該当する直接 loopback の例外を追加します:
localnet 127.0.0.0/255.0.0.0
localnet ::1/128これらの規則は数値の loopback 宛先ではチェーンを迂回します。提供されている上流の設定は proxy_dns を使ったホスト名照合の制限を記述しているため、その経路を診断するときはデバッガーの実際の数値 loopback アドレスを優先してください。リモート DNS マッピングのサブネットを同じ除外範囲に入れないでください。
インタープリターの同一性を保つ
ラッパーで /usr/bin/python3 を使うと、プロジェクトの .venv とは別の環境が黙って選ばれることがあります。その場合、別のインタープリターが起動したのに、不足パッケージがプロキシ関連の障害のように見えます。
Proxychains は対応している動的ライブラリの横取りに依存します。IDE がラッパーをインタープリターとして受け付けないこと、保護された macOS プロセス、静的リンクされたネットワーククライアントは別個の互換性条件です。構成を目的の Python プロセスに限定し、IDE の設定で選択されたインタープリターを確認してください。