Mantenha a conexão do depurador do PyCharm fora da cadeia de proxy

O Proxychains em torno de um processo de depuração Python pode capturar duas conexões diferentes: a conexão de serviço de saída do script e sua conexão local de volta ao PyCharm. O depurador precisa que a segunda permaneça local.

Onde a IDE e o host suportam um wrapper de interpretador, aponte-o para o interpretador real do projeto:

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

Substitua os dois caminhos dos executáveis e o caminho da configuração. Encaminhar "$@" preserva os argumentos individuais do depurador da IDE. O exec impede que o processo iniciado deixe um shell de wrapper desnecessário entre a IDE e seu filho.

Nessa configuração dedicada do Proxychains, mantenha a cadeia pretendida e acrescente a exceção de loopback direto apropriada:

localnet 127.0.0.0/255.0.0.0
localnet ::1/128

Essas regras contornam a cadeia para destinos numéricos de loopback. A configuração de origem fornecida documenta restrições para correspondência de nomes de host com proxy_dns, portanto, ao diagnosticar esse caminho, prefira o endereço numérico real de loopback do depurador. Não coloque a sub-rede de mapeamento DNS remoto dentro do mesmo intervalo excluído.

Preserve a identidade do interpretador

Usar /usr/bin/python3 no wrapper pode selecionar silenciosamente outro ambiente do .venv do projeto. Os pacotes ausentes então parecem uma falha relacionada ao proxy, embora outro interpretador tenha sido iniciado.

O Proxychains depende da interceptação suportada de bibliotecas dinâmicas. Uma IDE que rejeita um wrapper como interpretador, um processo macOS protegido ou um cliente de rede ligado estaticamente são uma condição de compatibilidade separada. Limite o arranjo ao processo Python pretendido e verifique o interpretador selecionado na configuração da IDE.