프록시 설정 두 가지가 의도하지 않은 체인을 만들 수 있습니다

애플리케이션은 프록시 B를 가리키지만, 프록시 A용으로 구성된 래퍼를 통해 실행되었습니다. 웹사이트는 어느 출구를 볼까요? 답은 래퍼가 어떤 연결을 가로채는지에 달려 있습니다.

단순한 중첩 구성에서 애플리케이션은 먼저 B에 연결을 시도합니다. 래퍼가 그 연결을 가로채 A를 통해 전달합니다. 그다음 애플리케이션은 생성된 스트림 위에서 B의 프록시 프로토콜을 사용하고, B가 최종 웹사이트 연결을 수행합니다.

application → wrapper proxy A → application proxy B → website

웹사이트는 B의 최종 외부 연결을 봅니다. B는 A를 통해 도착한 연결을 봅니다. 이는 래퍼가 애플리케이션 자체의 프록시 설정을 조용히 덮어쓰는 것과 다릅니다.

단순한 그림에는 조건이 있습니다

우회 규칙, 지원되지 않는 소켓 호출, 기존 프로세스, 각 제품의 가로채기 모델이 경로를 바꿀 수 있습니다. 일부 래퍼는 자체 프록시나 선택한 목적지를 제외할 수 있습니다. 모든 도구 조합이 같은 방식으로 동작한다고 가정하지 마세요.

proxychains-ng 설명은 가로채기 방식과 한계를 설명합니다. 네이티브 프록시 지원을 쓰는 프로그램도 여전히 그 프록시로 네트워크 연결을 하며, 이것이 가로채기의 후보 중 하나입니다.

인증되지 않은 공개 엔드포인트의 의도적인 체인을 위해서는 무료 프록시 목록이 각 도구와 프로토콜이 맞아야 하는 후보를 제공합니다. 예기치 않은 출구의 경우 세 주소를 따로 기록하세요. 애플리케이션이 고른 엔드포인트, 래퍼가 고른 엔드포인트, 그리고 웹사이트가 보는 결과입니다. 브라우저 설정만 보면 중간 계층을 놓칩니다.

의도한 동작을 확립하는 동안 하나의 경로를 사용하고, 체인이 필요할 때만 다른 경로를 추가하세요. 추가 홉은 실패 지점과 다른 신뢰 관계를 더할 수 있습니다. 식별 쿠키를 자동으로 지우거나 애플리케이션의 모든 연결을 같은 경로로 만들지는 않습니다.