Proxychains alrededor de un proceso de depuración de Python puede capturar dos conexiones distintas: la conexión de servicio saliente del script y su conexión local de vuelta a PyCharm. El depurador necesita que la segunda permanezca local.

Donde el IDE y el host admiten un envoltorio de intérprete, apúntalo al intérprete real del proyecto:

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

Sustituye ambas rutas de los ejecutables y la ruta de configuración. Reenviar "$@" conserva los argumentos individuales del depurador del IDE. exec evita que el proceso lanzado deje una shell de envoltorio innecesaria entre el IDE y su hijo.

En esa configuración dedicada de Proxychains, mantén la cadena prevista y añade la excepción directa de loopback correspondiente:

localnet 127.0.0.0/255.0.0.0
localnet ::1/128

Estas reglas omiten la cadena para destinos numéricos de loopback. La configuración de origen incluida documenta restricciones para la coincidencia de nombres de host con proxy_dns, así que, al diagnosticar esa ruta, prefiere la dirección numérica real de loopback del depurador. No coloques la subred de mapeo DNS remoto dentro del mismo rango excluido.

Conserva la identidad del intérprete

Usar /usr/bin/python3 en el envoltorio puede seleccionar en silencio otro entorno del .venv del proyecto. Entonces los paquetes que faltan parecen un fallo relacionado con el proxy, aunque se haya iniciado otro intérprete.

Proxychains se apoya en la intercepción admitida de bibliotecas dinámicas. Que un IDE rechace un envoltorio como intérprete, un proceso protegido de macOS o un cliente de red enlazado estáticamente es una condición de compatibilidad aparte. Limita la disposición al proceso de Python previsto y verifica el intérprete seleccionado en la configuración del IDE.

Artículos relacionados