프록시가 작동 중인지 확인하는 방법 (그리고 작동을 멈추는 이유 중 하나는 무엇인가요?) 중지하는 이유와 대처 방법에 대해 설명합니다.) 자연스럽게 원본 의미를 유지하도록 합니다.

어제는 잘 작동하던 프록시가 오늘 완전히 죽어 있을 수 있습니다. 이것이 바로 무료 공개 프록시 서버의 본질입니다. 작업 중에 그 사실을 뒤늦게 깨닫는 것보다, 프록시가 작동을 멈추는 이유, 가동 시간과 응답 시간 수치의 실제 의미, 그리고 프록시에 의존하기 전에 프록시가 실제로 살아 있는지 확인하는 방법을 이해하는 것이 좋습니다. 이 글에서는 이 세 가지를 모두 다룹니다.

프록시가 작동을 멈추는 이유

무료 프록시는 일반적으로 서비스 계약이 없는 공유, 비관리 또는 재목적 인프라에서 실행되므로 작동 중이던 프록시가 죽을 수 있는 일반적인 이유는 다음과 같습니다.

• 서버가 오프라인 상태가 됩니다. 이를 운영하는 주체가 서버를 내리거나, 다운되거나, 호스팅이 단순히 만료됩니다.
• 과부하가 걸립니다. 무료 프록시는 이를 찾는 모든 사람이 공유하며, 너무 많은 동시 사용자로 인해 타임아웃이 발생하거나 새로운 연결을 거부할 수 있습니다.
• 재할당되거나 재설정됩니다. IP가 완전히 다른 용도로 재목적되어 프록시 역할을 하던 포트가 닫힐 수 있습니다.
• 자동화된 검사를 차단하기 시작합니다. 일부 프록시는 봇이나 스캐너처럼 보이는 트래픽을 거부하도록 구성되어 있어, 정상적으로 작동하는 프록시도 검사기에는 죽은 것처럼 보일 수 있습니다.
• 대상 사이트가 특정 프록시를 차단하기 시작합니다. 일반적인 상황에서는 프록시에 문제없이 도달할 수 있지만, 특정 웹사이트가 비정상적인 트래픽을 감지한 후 해당 IP를 블랙리스트에 올렸을 수 있습니다.

그렇다고 해서 무료 프록시가 일반적으로 신뢰할 수 없다는 뜻은 아니며, 개별 프록시의 수명이 짧고 예측 불가능하다는 뜻입니다. 이것이 바로 이 사이트의 목록이 정적 스냅샷을 표시하는 대신 15분마다 스스로 갱신되는 이유입니다.

프록시가 작동하지 않는 징후

전용 검사기를 찾기 전에, 다음과 같은 몇 가지 증상을 스스로 인지해 두는 것이 좋습니다.

• 프록시를 통과하는 페이지의 시간이 초과되거나 로딩이 끝나지 않습니다.
• 시간 초과가 발생하는 대신 연결이 즉시 거부됩니다.
• 응답이 오지만 프록시를 전혀 거치지 않은 것처럼 보입니다(실제 IP가 노출됨).
• 간헐적으로 작동합니다(어떤 때는 연결되고 어떤 때는 연결되지 않음). 이는 완전히 죽은 서버라기보다는 과부하된 서버를 나타냅니다.
• 요청은 성공하지만 일반적인 브라우징에 비해 비정상적으로 느리게 돌아오며, 이는 서버가 다른 사용자들로부터 무거운 부하를 받고 있음을 시사합니다.

가동 시간과 응답 시간이 실제로 측정하는 것

이 사이트의 프록시 목록에서는 의존하기 전에 이해해 둘 가치가 있는 두 가지 라이브 지표를 모든 항목에 표시합니다. 가동 시간(Uptime)은 해당 프록시가 성공적으로 응답한 최근 검사의 비율입니다. 90%인 프록시는 최근에 신뢰할 수 있었던 반면, 20%인 프록시는 성공하는 것보다 훨씬 더 자주 실패했습니다. 응답 시간(Response time)은 가장 최근의 성공적인 연결에 걸린 시간(밀리초 단위)이며, 낮을수록 빠릅니다. 목록의 기본값인 "가장 빠른 응답(Fastest response)" 정렬은 단순히 가장 낮은 응답 시간만을 쫓지 않습니다. 상태가 양호한 가동 시간(초록색 또는 주황색)을 가진 프록시를 신뢰할 수 없는 프록시보다 먼저 그룹화하고, 그 그룹 내에서만 속도순으로 정렬합니다. 절반의 확률로 실패하는 엄청나게 빠른 프록시는 실제로 좋은 선택이 아니기 때문입니다.

프록시를 수동으로 확인하는 방법

가장 간단한 수동 테스트는 브라우저에서 프록시를 설정하고(PC 및 모바일에서 프록시를 설정하는 방법 참조) IP 조회 사이트를 방문하는 것입니다. 표시되는 위치와 IP가 자신의 연결이 아니라 프록시와 일치한다면 작동하는 것입니다. 이는 단일 프록시를 확인하는 데는 좋지만, 테스트할 대상이 한두 개 이상일 때는 느리고 전적으로 수동이며, 후보들을 비교할 수 있는 응답 시간 수치를 제공하지 않습니다.

프록시 검사기(Proxy Checker)로 대량의 프록시를 확인하는 방법

단일 프록시를 넘어선 모든 작업에는 전용 검사기가 훨씬 더 빠릅니다. 이 사이트의 프록시 검사기 도구를 사용하면 전체 목록을 한 번에(배치당 최대 30개까지) 붙여넣고, 목록이 사용하는 프로토콜과 형식을 선택한 후, 각 프록시를 통해 병렬로 연결하여 일반적으로 단 몇 초 만에 완료할 수 있습니다. 설치나 계정이 필요하지 않으며, 제출한 모든 내용은 이후에 저장되지 않습니다.

사용 방법: 프록시를 붙여넣고(줄당 하나), HTTP, HTTPS, SOCKS4 또는 SOCKS5 중 어떤 것인지 선택하고, 목록과 일치하는 형식(일반 host:port 또는 자격 증명이 포함된 host:port:username:password 같은 형식 중 하나)을 선택한 뒤 프록시 확인(Check Proxy)을 클릭합니다. 각 프록시는 단순한 핑이나 열린 포트 확인이 아니라 실제 라이브 엔드포인트와의 실제 연결로 테스트됩니다. 이는 프록시 포트가 기술적으로 열려 있더라도 프록시 자체의 설정이 잘못되었거나 실제로 트래픽 전달을 거부할 수 있기 때문에 중요합니다.

결과 이해하기

확인된 각 프록시는 다음 두 가지 상태 중 하나로 반환됩니다.

• 활성(Alive):: 검사기가 이를 통해 실제 요청을 성공적으로 완료했습니다. 표시되는 IP, 국가, 도시는 목록이 주장하는 바가 아니라 해당 응답에서 직접 읽어온 것입니다. 이것이 프록시의 실제 현재 출구 지점입니다.
• 비활성(Dead): 연결이 실패했거나, 시간이 초과되었거나, 사용 가능한 응답을 반환하지 않았습니다. 이것이 반드시 프록시가 영원히 사라졌다는 의미는 아니며, 일시적으로 과부하가 걸렸을 수 있지만 지금 당장 그에 의존해서는 안 된다는 뜻입니다.

또한 검사기는 살아 있는 모든 프록시에 대해 밀리초 단위의 응답 시간을 보고하므로, 어떤 프록시가 실제로 사용 가능한지 알게 된 후 일괄 처리 항목을 속도순으로 빠르게 정렬하는 방법으로도 두 배의 효과를 낼 수 있습니다. 작동할 것으로 예상했던 프록시가 죽은 상태로 나오면, 완전히 폐기하기 전에 1분이나 2분 정도 후에 다시 시도해 볼 가치가 있습니다. 일시적으로 과부하된 서버는 복구될 수 있지만 진정으로 오프라인 상태인 서버는 그렇지 않기 때문입니다.

반복 확인 자동화하기

동일한 회전식 프록시를 정기적으로 사용하는 경우 브라우저에서 하나씩 확인하는 것은 금방 지루해지며, 웹 기반 프록시 검사기조차도 매번 수동 방문이 필요합니다. (예를 들어 각 스크래핑 실행 전에) 일정에 따라 프록시를 확인해야 하는 워크플로우의 경우, 동일한 기본 아이디어가 프로그래밍 방식으로 적용됩니다. 짧은 시간 초과와 함께 각 프록시를 통해 알려진 엔드포인트로 실제 요청을 보내고, 성공적인 응답은 "활성"으로, 시간 초과나 오류는 "비활성"으로 처리합니다. (자동화 중인 언어의) 대부분의 HTTP 클라이언트 라이브러리는 프록시를 통한 요청 라우팅을 직접 지원하므로, 일괄 처리를 확인하고 응답한 항목만 유지하는 작은 스크립트를 간단하게 빌드할 수 있습니다. 이는 프록시 검사기 도구가 실행하는 것과 정확히 같은 논리이며, 브라우저 대신 사용자 자신의 파이프라인에 연결된 것뿐입니다.

일반적인 질문에 대한 빠른 답변

프록시를 통해 여전히 브라우징할 수 있는데 검사기에서는 왜 프록시가 죽었다고 나오나요?

이는 일반적으로 프록시에 간헐적인 과부하가 걸렸음을 의미합니다. 일부 요청은 처리할 수 있지만 검사기가 보낸 특정 요청은 처리하지 못하거나, 검사기의 더 엄격한 시간 제한 하에서 시간 초과가 발생한 것입니다. 잠시 기다린 후 다시 시도하세요.

프록시가 "활성(alive)" 상태이지만 여전히 사용하기에 안전하지 않을 수 있나요?

네. "활성"은 현재 트래픽을 성공적으로 전달하고 있음을 확인할 뿐, 누가 운영하는지 또는 얼마나 신뢰할 수 있는지를 의미하지는 않습니다. 상태와 관계없이 모든 무료 프록시는 검증되지 않은 것으로 취급하고, 그중 어떤 프록시를 통해서도 민감한 로그인이나 결제를 피하세요.

빠른 응답 시간이 좋은 프록시를 보장하나요?

그 자체만으로는 아닙니다. 프록시는 빠르지만 신뢰할 수 없거나(낮은 가동 시간), 요구 사항에 지리적으로 맞지 않을 수 있습니다. 응답 시간을 단독으로 보지 말고 가동 시간 및 위치와 함께 확인하세요.

정기적으로 사용하는 프록시는 얼마나 자주 다시 확인해야 하나요?

무료 프록시가 얼마나 빨리 상태를 바꿀 수 있는지 고려할 때 사용 직전이 가장 안전합니다. 동일한 프록시에 반복적으로 의존하는 경우 최소한 매일 다시 확인하세요.

죽은 프록시는 나중에 다시 시도해 볼 가치가 있나요?

종종 그렇습니다. 일시적으로 과부하되어 검사에 실패한 프록시는 몇 분 또는 몇 시간 안에 복구될 수 있으므로, 단 한 번의 검사 실패 후에 영원히 폐기하는 것보다 중요했던 프록시를 다시 테스트하는 것이 합리적입니다. 단, 특정 프록시가 장기적으로 계속 사용 가능할 것에 의존하는 워크플로우를 구축하지는 마세요.

검사기가 프록시 자체의 속도를 떨어뜨리거나 영향을 미치나요?

아니요. 검사는 단일 경량 요청이며, 프록시를 통해 하나의 작은 페이지를 로드하는 것과 비슷합니다. 다른 간단하고 정상적인 사용보다 프록시에 더 많은 영향을 미치지 않습니다.

신뢰할 수 있는 결과를 위한 모범 사례

1. 한 번뿐만 아니라 매 세션 전에 다시 확인하세요. 프록시의 상태는 몇 분 안에 바뀔 수 있으므로 "아까는 작동했다"는 것이 보장이 되지 않습니다.
2. 사용하려는 동일한 배치로 테스트하세요. 작업에 여러 프록시를 번갈아 사용하는 경우, 오래된 검사에 의존하기보다는 시작하기 직전에 모든 프록시를 함께 확인하세요.
3. 필요한 것보다 더 많은 후보를 유지하세요. 작업에 3개의 작동하는 프록시가 필요한 경우 6~8개를 확인하세요. 특히 무료 목록의 경우 일부는 필연적으로 죽어 있을 것입니다.
4. 목록과 형식을 정확히 일치시키세요. 파싱 불일치(잘못된 형식 선택)는 프록시가 실제로 양호하더라도 모든 프록시를 유효하지 않은 것으로 표시합니다. 형식 드롭다운이 목록의 구조와 일치하는지 다시 확인하세요.
5. 단일 검사를 과도하게 신뢰하지 마세요. 방금 통과한 프록시도 특히 빠른 확인 요청보다 사용량이 더 많은 경우 실제 사용 시 몇 초 후에 실패할 수 있습니다. "활성"을 영구적인 보장이 아니라 "현재 도달 가능"으로 취급하세요.

무료 프록시는 본질적으로 유동적인 대상이지만, 의존하기 전에 확인하는 것은 몇 초밖에 걸리지 않으며 애초에 작동하지 않을 연결을 디버깅하는 훨씬 더 큰 시간 비용을 절약해 줍니다.