공개 목록에는 이미 연결 수락을 중단한 엔드포인트가 있을 수 있습니다. 이는 프록시 실패의 흔한 원인이지만 유일한 원인은 아닙니다. 잘못된 프로토콜, 우회 설정, 차단된 포트, 웹사이트의 출구 IP 거부도 같은 증상을 만들 수 있습니다.

앱을 바꾸기 전에 목록 항목 확인하기

IP, 포트, 프로토콜을 다시 복사하세요. 포트 숫자 하나가 빠지거나 HTTP와 SOCKS가 맞지 않는 것만으로도 핸드셰이크가 실패합니다. 포트 8080이나 1080만 보고 프로토콜을 추측하지 말고, 서비스가 실제로 제공하지 않았다면 사용자 이름도 추가하지 마세요.

HTTP 엔드포인트라면 짧은 curl 요청으로 브라우저 확장 기능과 시스템 설정을 테스트에서 분리할 수 있습니다.

curl --proxy http://203.0.113.10:8080 --noproxy '' --connect-timeout 5 --max-time 15 --verbose https://example.com/

문서 예제 주소를 실제 항목으로 바꾸세요. SOCKS5 엔드포인트는 실제 포트와 해당 SOCKS 스킴을 사용하세요.

처음 발생한 실패 살펴보기

결과확인할 가능성이 큰 지점
연결 거부포트가 닫혀 있거나 장치가 연결을 적극적으로 거부했습니다.
연결 시간 초과경로, 필터링 또는 서비스 문제로 제한 시간 안에 연결을 설정하지 못했습니다.
예상과 다른 프록시 핸드셰이크 응답선택한 프로토콜이 서비스와 맞지 않을 수 있습니다.
407프록시가 인증을 요구합니다.
CONNECT 거부프록시가 해당 대상이나 포트를 제한할 수 있습니다.
웹사이트가 403 또는 429 반환요청이 HTTP 서버에 도달했지만 서버가 이를 거부하거나 제한했습니다. 어떤 서버가 응답했는지 확인하세요.

TCP 연결 성공은 첫 단계일 뿐입니다. 해당 포트의 서비스가 선택한 프록시 프로토콜이 아니라면 요청은 곧바로 다음 단계에서 실패할 수 있습니다.

두 가지 비교하기

같은 프로토콜의 두 번째 프록시로 같은 대상에 접속해 보세요. 첫 엔드포인트만 연결 설정 중 실패한다면 문제를 해당 엔드포인트나 경로로 좁힐 수 있습니다. 다음에는 첫 프록시로 다른 일반 대상을 시도하세요. 웹사이트 하나만 실패한다면 프록시 전체가 죽었다고 단정하지 말고 대상별 정책을 조사하세요.

직접 접속이 가능할 때는 직접 요청도 유용한 비교입니다. 상속된 프록시 변수가 이른바 직접 테스트를 몰래 프록시 경로에 남겨 두지 않도록 우회를 명시하세요.

항목 테스트를 중단할 시점 판단하기

시간을 제한한 여러 요청이 같은 연결 단계에서 실패한다면 대기 시간을 몇 분으로 늘리기보다 무료 프록시 목록에서 다른 항목을 고르세요. 보고해야 한다면 정확한 오류를 저장하세요. 반복해서 재연결해도 닫힌 포트나 제거된 엔드포인트는 복구되지 않습니다.

모든 항목이 실패한다면 한 걸음 물러서서 확인하세요. 클라이언트 설정, 네트워크의 송신 규칙, 프록시 없이 대상에 접근 가능한지를 살펴보세요. 모든 요청에 공통인 문제는 목록 전체를 버릴 충분한 근거가 아닙니다.

관련 글