프록시 연결이 실패하면 프록시 서비스, 인증과 프로토콜, 클라이언트 설정, 대상 사이트 순서로 확인하세요. 각 단계의 명확한 판단 기준을 이용해 설정을 바꾸기 전에 문제가 발생한 계층을 먼저 찾는 것이 핵심입니다.
프록시를 입력한 뒤 테스트 버튼에서 실패가 표시될 수 있습니다. 이때 가장 피해야 할 방법은 설정을 무작정 바꾸는 것입니다. 포트, 프로토콜, 노드를 계속 바꾸다 보면 결국 연결되더라도 무엇이 효과가 있었는지 알 수 없습니다.
원인은 대체로 네 계층에 있습니다. 프록시 서비스 자체, 인증과 프로토콜, 클라이언트 설정, 대상 사이트입니다. 프록시에서 바깥쪽으로 이 순서대로 확인하세요.
먼저 프록시 자체를 분리해서 테스트하기
처음부터 업무용 도구 안에서 확인하지 마세요. 수동 프록시 설정을 지원하는 일반 브라우저나 시스템 프록시 설정에 해당 프록시를 직접 넣고 인터넷에 접속되는지 확인합니다. 이 단계의 목적은 프록시와 업무 환경을 분리하는 것입니다.
이 환경에서도 연결되지 않는다면 문제는 프록시 자체에 있습니다. 만료되었거나 비활성화되었을 수 있고, 출구 노드에 장애가 있거나 공급자가 접근 제한을 걸었을 수도 있습니다. 이 경우 이후 단계는 진행할 필요 없이 프록시 공급자에게 상태와 사용량을 확인하세요.
여기서는 연결된다면 프록시 자체는 살아 있습니다. 문제는 설정이나 연결 경로에 있으므로 다음 단계로 진행합니다.
판단 기준은 간단합니다. 같은 인증 정보가 다른 곳에서 작동한다면 인증 정보 자체는 문제가 아닐 가능성이 높습니다.
인증과 프로토콜을 맞추기
인증 정보가 맞는데도 연결되지 않는다면 다음으로 프로토콜을 의심해야 합니다. 흔한 불일치는 세 가지입니다. 공급자가 SOCKS5를 제공했는데 환경에서는 HTTP를 선택한 경우, 직접 만든 SSH 터널을 SOCKS5로 설정한 경우, 또는 하나의 프록시가 여러 프로토콜을 지원하지만 프로토콜마다 포트가 달라 다른 프로토콜의 포트를 입력한 경우입니다.
오류 문구를 판단 기준으로 사용하세요. 인증 실패나 인증 정보 오류가 나오면 사용자 이름과 비밀번호를 확인합니다. 복사하여 붙여넣는 과정에서 들어간 공백이나 줄바꿈이 없는지, 사용자 이름의 특수 문자를 요구대로 이스케이프했는지도 확인하세요. 프로토콜 오류나 핸드셰이크 실패라면 프로토콜 유형과 포트를 확인합니다.
사용자 이름이나 비밀번호 같은 필드는 한 번 직접 입력해 비교해 보는 것이 좋습니다. 보이지 않는 문자가 원인인 실패는 눈으로 확인하기 어렵습니다.
클라이언트 설정이 실제로 적용됐는지 확인하기
이 단계에서는 더 눈에 띄지 않는 질문을 확인합니다. 설정은 올바른데, 실제로 적용된 상태일까요?
흔한 경우는 두 가지입니다. 첫째, 설정 자체가 적용되지 않은 경우입니다. 변경 사항을 저장하지 않았거나 다른 환경의 설정을 수정했거나 이전 세션이 계속 실행 중일 수 있습니다. 둘째, 설정은 적용됐지만 다른 설정이 덮어쓴 경우입니다. 환경 안에 별도의 네트워크 스위치가 있을 수 있고, 확장 프로그램이 프록시를 직접 제어할 수 있으며, 시스템 수준의 프록시 설정이 더 높은 우선순위를 가질 수도 있습니다.
출구 주소를 확인하세요. 연결 후 현재 출구 주소를 표시하는 페이지에 접속합니다. 로컬 주소가 아니라 프록시 주소가 보여야 합니다. 여전히 로컬 주소가 보인다면 테스트 버튼이 통과했다고 표시하더라도 실제 요청은 프록시를 거치지 않은 것입니다.
비교 방법은 간단합니다. 같은 환경에서 프록시를 한 번 켜고 한 번 끈 뒤 출구 주소가 바뀌는지 확인합니다. 바뀌지 않으면 문제는 클라이언트 쪽에 있습니다. 여러 환경을 동시에 실행 중이라면 각각의 출구를 따로 확인해야 합니다. PurpleMark처럼 계정별로 환경을 분리하는 도구가 프록시를 연결할 때 중요하게 보는 것도 바로 이 지점입니다.
대상 사이트의 거부 패턴 확인하기
모든 계층이 연결되고 프록시도 확실히 적용됐는데 업무 페이지가 여전히 열리지 않는다면, 프록시를 계속 바꾸기보다 대상 사이트의 반응을 살펴봐야 합니다.
이 유형은 대체로 특징이 분명합니다. 연결과 핸드셰이크는 완료되지만 요청이 403을 반환하거나 재설정됩니다. 페이지는 열리지만 로그인이나 게시 같은 동작이 거부됩니다. 같은 출구로 다른 사이트는 정상인데 특정 사이트만 실패합니다. 또는 간헐적으로 실패하며, 이는 출구나 연결 경로의 속도 제한 또는 동시 요청 제한을 의미할 수 있습니다.
핵심은 연결 계층과 업무 계층을 분리하는 것입니다. 아예 연결되지 않으면 프록시 문제일 가능성이 높습니다. 연결은 되지만 거부된다면 출구 품질이나 접근 빈도가 원인인 경우가 많습니다. 데이터센터 IP와 많이 재사용된 공유 IP는 업무 계층에서 차단될 가능성이 더 높습니다. 주거용 IP가 상대적으로 나을 수 있지만 만능은 아닙니다. 요청 빈도, 동시 요청 수, 접속 시간대도 결과에 영향을 줍니다.
문제 해결 시 지킬 세 가지 습관
한 번에 한 가지만 바꾸세요. 프로토콜과 노드를 동시에 바꾸면 연결에 성공하더라도 무엇이 해결책이었는지 알 수 없고, 다음에 같은 문제를 다시 겪을 수 있습니다.
먼저 기록하고 그다음 조정하세요. 정상 작동하는 설정의 주소, 포트, 프로토콜, 인증 방식을 적어 두면 다음에 문제가 생겼을 때 처음부터 다시 확인하는 것보다 훨씬 빠르게 비교할 수 있습니다.
반복 재시도보다 비교 테스트를 우선하세요. 설정이 올바른데도 연결되지 않는다면 테스트 버튼을 계속 누르는 것은 새로운 정보를 주지 않습니다. 다른 네트워크 환경이나 다른 프록시를 사용해 대조 테스트를 하는 편이 낫습니다.
