프록시 연결이 실패하면 세 계층으로 점검합니다. 먼저 IP 변경과 출구 위치를 확인하고, DNS·시간 초과·인증서 오류를 구분한 뒤, 마지막으로 인증 정보·포트·프로토콜을 확인합니다.
프록시를 설정했고 아이디와 비밀번호도 맞는데 연결 검사에서는 실패가 표시될 수 있습니다. 많은 사람은 이때 바로 프록시 제공업체에 연락하고, 노드를 바꾸거나 포트를 변경하고, 고객 지원을 재촉합니다. 하지만 실패 원인은 전체 연결 경로 어디에나 있을 수 있고 프록시는 그중 한 부분일 뿐이므로 효율이 낮은 경우가 많습니다.
무작정 하나씩 바꾸기보다 바깥에서 안쪽으로 고정된 순서를 따르는 것이 좋습니다. 먼저 출구가 실제로 적용됐는지 확인하고, 다음으로 네트워크 경로가 통하는지 본 뒤, 그다음 애플리케이션 계층의 인증과 프로토콜을 점검합니다. 이 세 계층을 순서대로 보면 대부분의 문제를 위치시킬 수 있습니다.
출구가 실제로 적용됐는가
설정이 성공한 것처럼 보이기 때문에 이 단계는 쉽게 건너뜁니다. 하지만 설정이 성공한 것과 실제 트래픽이 프록시를 통해 나가는 것은 서로 다른 문제입니다.
두 가지를 확인하세요. 첫째, IP가 바뀌었는지 봅니다. 프록시를 사용하지 않을 때의 공인 IP를 기록하고 프록시를 켠 뒤 다시 확인합니다. 둘이 같다면 트래픽이 프록시로 나가지 않는 것이므로 이후 점검은 의미가 없습니다. 둘째, 위치가 맞는지 봅니다. 프록시 상세 정보에는 보통 국가, 지역, 주·도, 도시, 소수점 이하 6자리의 위도·경도와 우편번호가 제공됩니다. 구매한 지역 정보와 비교하세요. 시스템 시간대가 출구 지역과 명확히 맞지 않는 경우도 위험 신호입니다.
출구가 적용되지 않는 원인은 제공업체보다 로컬에 남은 설정인 경우가 많습니다. 이전에 사용한 네트워크 도구가 종료될 때 정리를 제대로 하지 않았다면 시스템에 HTTP_PROXY, HTTPS_PROXY 같은 환경 변수가 남아 있거나 macOS의 웹 프록시나 SOCKS 프록시 스위치가 켜져 있을 수 있습니다. 이 경우 클라이언트는 시스템 프록시를 따르고 있다고 생각하지만 실제 요청은 이를 우회할 수 있습니다. 이런 잔여 설정을 지우고 다시 테스트하는 것이 프록시를 처음부터 다시 설정하는 것보다 더 유용한 경우가 많습니다.
네트워크 경로에서 흔한 세 가지 오류
출구에 문제가 없음을 확인했다면 요청이 실제 목적지까지 도달하는지 확인합니다.
첫 번째 막힘은 DNS 해석입니다. 이름 해석이 실패하거나, 대상 서비스를 가리켜야 할 도메인이 엉뚱한 주소로 해석되는 등 결과가 명백히 잘못될 수 있습니다. 공용 DNS로 다시 해석하거나 로컬 DNS 캐시를 지운 뒤 정상화되는지 확인하세요.
두 번째는 연결 시간 초과입니다. 방화벽이나 보안 소프트웨어가 포트를 차단하면 계속 로딩되다가 시간 초과가 발생합니다. 포트 허용 규칙을 확인하고 기업 내부망이나 공용 Wi-Fi 같은 환경 자체에 제한이 있는지도 살펴보세요. 간단한 판별 방법은 프록시 없이 직접 연결하는 것입니다. 이 경우에도 어떤 웹사이트도 열리지 않으면 문제는 프록시가 아니라 기본 네트워크에 있습니다. 라우터를 재시작하거나 모바일 핫스팟으로 전환해 확인할 수 있습니다.
인증서 오류는 별도로 봐야 합니다. 신뢰할 수 없는 인증서나 핸드셰이크 실패가 표시되면 많은 사람이 먼저 트래픽 복호화나 인증서 교체를 의심합니다. 실제로 그럴 수 있지만 더 잘 드러나지 않는 원인도 있습니다. 바로 로컬 시간이 잘못된 경우입니다. 많은 인증 및 세션 메커니즘은 타임스탬프에 의존합니다. 로컬 시간과 서버 시간의 차이가 5분을 넘으면 서명 검증이 실패해 연결이 거부될 수 있고, HTTPS에서는 인증서 검증 실패로 나타납니다. 인증서 오류가 보이면 시스템 시간 동기화 상태도 확인하세요. 이상이 있다면 자동 동기화를 켜고 즉시 시간을 보정한 뒤 클라이언트를 재시작해 다시 테스트합니다.
인증과 프로토콜을 잘못 입력하지 말 것
프록시 서버까지는 연결되는데 트래픽이 여전히 통하지 않으면 문제는 대개 애플리케이션 계층에 있습니다.
가장 흔한 것은 인증 정보입니다. 프록시의 사용자 이름, 비밀번호, 인증 방식은 제공업체가 준 정보와 일치해야 합니다. 비밀번호를 바꿨는데 설정에 반영하지 않은 경우도 흔합니다. 수동 설정 모드에서는 입력한 포트 번호가 프록시 도구 자체가 수신 대기하는 포트와 같은지도 확인해야 합니다. 숫자가 비슷해 보일 수 있지만 포트를 잘못 넣으면 전혀 연결되지 않습니다.
두 번째는 프로토콜 불일치입니다. HTTP, HTTPS, SOCKS5는 서로 섞어 사용할 수 없습니다. 제공업체가 SOCKS5를 줬는데 설정에 HTTP를 입력하면 검사는 반드시 실패합니다. 또한 일부 프록시는 대상이나 프로토콜을 제한하므로, 프록시가 대상 사이트와 대상 포트 접근을 허용하는지도 확인하세요.
노드 문제인지 설정 문제인지 가장 빠르게 구분하는 방법은 다른 노드로 바꿔 테스트하는 것입니다. 바꾼 뒤 작동하면 원래 노드의 문제입니다. 바꿔도 계속 실패하면 설정과 네트워크 경로로 돌아가야 합니다. 이때 여러 매개변수를 계속 한꺼번에 바꾸지 말고 한 번에 하나의 변수만 변경한 뒤 결과를 기록하세요. 그렇지 않으면 자신의 변경 작업이 실제 원인을 가릴 수 있습니다.
연결됨이 곧 사용 가능한 환경을 뜻하지는 않는다
흔한 함정이 하나 더 있습니다. 프록시는 정상 연결로 표시되는데 계정이 계속 위험 관리에 자주 걸리는 경우입니다. 문제는 연결 가능 여부가 아니라 이 출구가 정상 사용자 환경처럼 보이는가에 있을 수 있습니다.
확인할 항목은 비슷합니다. 출구 위치가 계정 등록 지역과 일치하는지, IP 유형이 적절한지, 해당 IP가 이전에 대상 사이트에서 표시된 적이 있는지 확인합니다. 플랫폼은 데이터센터 IP와 주거용 IP에 서로 다른 신뢰 수준을 적용할 수 있습니다. 같은 IP에서 과거에 대량의 비정상 활동이 있었다면 이후 사용자에게도 영향을 줄 수 있습니다. 연결 테스트를 통과한 뒤에는 출구의 청결도도 몇 분 정도 확인하는 것이 좋습니다.
한 기기에서 여러 환경을 운영해야 한다면 출구를 일대일로 대응시키는 것이 좋습니다. 각 환경에 전용 출구를 두면 문제가 생겼을 때 개별적으로 위치를 찾을 수 있고, 특정 출구가 표시돼도 해당 환경에만 영향이 가며 전체가 함께 끊기지 않습니다. PurpleMark의 다중 환경 관리도 이 논리에 따라 환경별로 출구를 따로 구성하고 격리합니다.
이 문제 해결 방법은 기술 교류를 위한 것입니다. 관련 도구와 서비스는 적용되는 법률과 규정을 준수하는 범위에서 사용하세요.
