Keep PyCharm’s Debugger Connection Off the Proxy Chain

Proxychains around a Python debug process can catch two different connections: the script’s outbound service connection and its local connection back to PyCharm. The debugger needs the latter to stay local.

Where the IDE and host support an interpreter wrapper, point it at the project’s actual interpreter:

#!/bin/sh
exec /usr/bin/proxychains4 -f /home/alex/proxychains-debug.conf "/home/alex/project/.venv/bin/python" "$@"

Replace both executable paths and the configuration path. Forwarding "$@" preserves the IDE’s individual debugger arguments. exec keeps the launched process from leaving an unnecessary wrapper shell between the IDE and its child.

In that dedicated Proxychains configuration, keep the intended chain and add the relevant direct loopback exception:

localnet 127.0.0.0/255.0.0.0
localnet ::1/128

These rules bypass the chain for numeric loopback destinations. The supplied upstream configuration documents restrictions for hostname matching with proxy_dns, so prefer the debugger’s actual numeric loopback address when diagnosing that path. Do not place the remote DNS mapping subnet inside the same excluded range.

Preserve the interpreter identity

Using /usr/bin/python3 in the wrapper can quietly select another environment from the project’s .venv. Missing packages then look like a proxy-related failure even though a different interpreter started.

Proxychains relies on supported dynamic-library interception. An IDE rejecting a wrapper as an interpreter, a protected macOS process or a statically linked network client is a separate compatibility condition. Keep the arrangement limited to the intended Python process and verify the selected interpreter in the IDE’s configuration.