PyCharm 디버거 연결을 프록시 체인 밖으로 유지하기
선택한 Python 인터프리터를 Proxychains용으로 감싸면서 인수와 디버거로 향하는 직접 loopback 경로를 유지합니다.
Python 디버그 프로세스를 Proxychains로 감싸면 서로 다른 두 연결이 잡힐 수 있습니다. 스크립트의 외부 서비스 연결과 PyCharm으로 돌아가는 로컬 연결입니다. 디버거는 후자가 로컬로 남아야 합니다.
IDE와 호스트가 인터프리터 래퍼를 지원한다면 프로젝트의 실제 인터프리터를 가리키게 하세요:
#!/bin/sh
exec /usr/bin/proxychains4 -f /home/alex/proxychains-debug.conf "/home/alex/project/.venv/bin/python" "$@"실행 파일의 두 경로와 설정 파일 경로를 바꿉니다. "$@"를 전달하면 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 설정에서 선택된 인터프리터를 확인하세요.