프록시 순환: IP가 바뀌는 시점

프록시 순환: IP가 바뀌는 시점

프록시 순환은 웹사이트가 트래픽을 받을 때 보게 되는 출구 IP를 바꿉니다. 새 요청을 보낼 때, 정해진 시간이 지난 뒤, 또는 애플리케이션이 다른 주소를 요청할 때 변경될 수 있습니다. 적절한 시점을 선택하면 독립적인 요청을 여러 IP에 분산하면서 서로 관련된 동작은 같은 IP로 처리할 수 있습니다.

고정 주소와 변경되는 주소 사이의 전반적인 선택은 고정 IP 프록시와 순환 프록시 비교에서 다룹니다. 여기서는 무엇이 변경을 유발하고 진행 중인 요청에 어떤 영향을 주는지 살펴봅니다.

순환할 때 무엇이 바뀌는가?

순환 게이트웨이를 사용하면 소프트웨어에 입력한 주소는 그대로인데 웹사이트에는 서로 다른 출구 IP가 표시될 수 있습니다. 같은 호스트 이름과 포트에 접속하고, 서비스가 웹사이트로 연결할 때 사용할 출구를 선택합니다.

예를 들어 가격 모니터링 프로그램이 하나의 공개 상품 페이지는 192.0.2.14로, 다른 페이지는 198.51.100.27로 가져올 수 있습니다. 이 주소들은 예시입니다. 모니터링 프로그램을 실행하는 컴퓨터의 인터넷 연결이 바뀐 것은 아닙니다. 요청이 서로 다른 출구를 거쳐 사이트에 도달하는 것입니다.

결과는 서로 별개인 두 가지 결정에 따라 달라집니다. 출구를 언제 다시 선택할지와 다음 출구를 어디에서 가져올지입니다. 타이머가 다른 가용 프록시를 선택하거나 모바일 모뎀을 다시 연결할 수 있습니다. 변경 계기는 같지만 실제 동작과 중단 여부는 다를 수 있습니다.

요청마다 순환

요청별 순환에서는 서비스가 독립적으로 전달할 수 있는 각 요청마다 출구를 새로 선택합니다. 같은 IP가 필요 없는 개별 상품 페이지, 공개 목록, 검색어 요청에 적합합니다. 여기서 “요청”이라는 말은 주의해서 해석해야 합니다. HTTPS 및 SOCKS5 TCP 트래픽에서는 일반적으로 대상에 대한 새 연결을 열 때 순환이 적용됩니다.

500개 상품 페이지에서 가격을 수집한다고 가정해 보세요. 각 페이지는 별도의 결과를 제공합니다. 서비스는 작업 전체를 하나의 주소로 보내는 대신 가용 출구에 해당 요청을 분산할 수 있습니다. 동시에 실행하는 여러 요청도 서로 다른 출구를 사용할 수 있습니다.

하나의 애플리케이션이 하나의 게이트웨이를 통해 같은 웹사이트로 세 요청을 순서대로 보냅니다. 이 예에서는 요청마다 새 연결을 엽니다. 게이트웨이는 출구 IP로 192.0.2.14, 198.51.100.27, 203.0.113.42를 선택합니다.

새로 선택하더라도 이전에 사용한 주소가 다시 나올 수 있습니다. 가용 풀은 유한하며, 선택이 무작위일 수도 있습니다. 요청별 순환만으로 500개 요청에 서로 다른 IP 500개가 보장되지는 않습니다.

요청과 연결은 다름

애플리케이션은 하나의 연결로 여러 HTTP 요청을 보낼 수 있습니다. 프록시를 통한 일반적인 HTTPS 연결에서는 먼저 대상까지 터널을 엽니다. 이후 암호화된 요청이 터널 안으로 이동하며, 프록시는 개별 요청을 읽지 않고 데이터를 전달합니다.

따라서 해당 터널의 출구는 그대로 유지됩니다. 요청별이라고 설명된 서비스도 애플리케이션이 새 터널이나 대상 연결을 열 때 다른 출구를 선택할 수 있습니다. 기존 터널을 재사용하면 이전 IP가 유지될 수 있습니다.

브라우저 페이지는 여러 연결로 많은 리소스를 불러올 수 있으며, 새로고침할 때 이미 열린 연결을 재사용할 수도 있습니다. 따라서 순환은 클릭 한 번, 탭 하나 또는 페이지 전체를 한 번 불러오는 동작과 일대일로 대응하지 않습니다.

정해진 간격으로 순환

시간 기반 순환에서는 IP 할당이 정해진 시간 동안 유지됩니다. 해당 시간이 지나면 서비스가 출구를 다시 선택합니다. 출구를 계속 사용할 수 있다면 관련 요청들이 그 시간 동안 할당된 주소를 함께 사용할 수 있습니다.

예를 들어 세션이 10:00에 시작하고 유지 시간이 5분이라고 가정합니다. 테스트는 같은 출구로 카탈로그를 열고, 필터를 적용하고, 다음 결과 페이지를 확인합니다. 10:05에 할당이 만료되면 이후의 새 연결은 다른 주소를 받을 수 있습니다. 여기의 5분은 예시이며 모든 서비스의 표준 간격이 아닙니다.

애플리케이션이 시간 기반 순환 게이트웨이를 사용합니다. 이 예에서 처음 5분 동안 요청 1, 2, 3은 192.0.2.14를 사용합니다. 만료 후 요청 4, 5, 6은 198.51.100.27을 사용합니다.

타이머가 언제 시작되는지 확인하세요. 세션의 첫 요청부터 시간을 셀 수도 있고, 프록시 포트의 일정에 따를 수도 있습니다. 다음 예정 변경이 1분 뒤라면 지금 작업을 시작해도 온전한 5분을 확보하지 못합니다. 별도의 비활성 시간 제한 때문에 할당이 더 일찍 종료될 수도 있습니다.

간격은 보통 특정 세션, 포트 또는 프록시 접속 설정에 적용됩니다. 계정의 모든 연결이 반드시 한꺼번에 순환하는 것은 아닙니다. 여러 작업에 별도의 IP 할당이 필요하다면 서비스가 지원하는 해당 분리 방식도 필요합니다.

여러 요청에서 할당된 출구를 유지하는 방식을 흔히 고정 세션이라고 합니다. 순환 서비스는 이 모드로 주소를 잠시 유지한 뒤 다시 선택할 수 있습니다.

필요할 때 순환

필요 시 순환에서는 사용자나 애플리케이션이 다른 출구를 요청할 시점을 정합니다. 서비스에 따라 대시보드 버튼, 순환 URL 또는 API 명령을 사용할 수 있습니다. 일부 서비스는 다른 프록시 세션을 시작할 때도 새 주소를 할당합니다.

서로 이어지는 여러 단계로 구성돼 있지만 소요 시간을 예측하기 어려운 작업에 유용합니다. 테스트에서 양식을 열고 제출한 뒤 확인 페이지를 기다릴 수 있습니다. 전체 과정에서 현재 출구를 유지하고, 다음 독립 테스트를 시작하기 전에 다른 주소의 할당을 요청할 수 있습니다.

첫 번째 작업의 관련된 세 단계는 출구 192.0.2.14를 사용합니다. 작업이 끝나면 애플리케이션이 Change IP 명령을 보냅니다. 다음 작업의 단계들은 198.51.100.27을 사용합니다.

필요 시 순환도 자동화할 수 있습니다. 작업을 완료하거나 정한 수의 요청을 보낸 뒤 애플리케이션이 변경 명령을 보내면 됩니다. “필요 시”는 전환 시점을 누가 결정하는지 설명하는 말입니다. 매번 사람이 버튼을 눌러야 한다는 뜻은 아닙니다.

제어 범위도 중요합니다. 명령이 하나의 세션, 프록시 포트 전체 또는 여러 연결이 공유하는 실제 모뎀에 영향을 줄 수 있습니다. 이 모든 연결의 할당을 변경한다면 해당 자원을 사용하는 다른 작업도 영향을 받을 수 있습니다.

이미 진행 중인 요청은 어떻게 되는가?

웹사이트에 대한 일반적인 TCP 연결에서 출구 IP는 해당 연결을 이루는 일부입니다. 요청과 응답은 동일하게 수립된 연결을 사용합니다. 순환한다고 미완료 교환을 다른 출구 IP로 그대로 옮길 수는 없습니다.

서비스마다 순환 경계를 처리하는 방식이 다를 수 있습니다. 기존 연결은 현재 출구에서 마치게 하고 이후 연결에 새 할당을 적용할 수 있습니다. 반대로 연결을 닫아 애플리케이션이 다시 연결하도록 할 수도 있습니다. 모뎀을 다시 연결하면 이를 통과하는 트래픽도 중단될 수 있습니다.

시간 기반 순환 직전에 내려받기를 시작하는 경우를 생각해 보세요. 연결을 계속 열어 두면 타이머가 만료된 뒤에도 이전 출구로 내려받기가 이어질 수 있습니다. 연결이 닫히면 애플리케이션이 내려받기를 다시 시작하거나, 지원되는 경우 이어받아야 합니다. 순환 간격만으로는 진행 중인 전송의 동작을 알 수 없습니다.

다음 IP는 어디에서 오는가?

풀에서 다른 출구 선택

풀 기반 서비스는 사용 가능한 출구를 선택합니다. 다음 연결은 같은 데이터센터 서버의 다른 IP, 다른 서버, 가정용 연결 또는 모바일 기기를 사용할 수 있습니다. 풀에서 출구를 선택할 때 이전 요청을 처리한 기기를 다시 연결할 필요는 없습니다.

위치 또는 네트워크 필터를 지원한다면 선택 가능한 출구가 해당 조건으로 제한됩니다. 같은 국가 안에서 다른 IP를 선택한다고 국가를 바꿀 필요는 없습니다. 선택 범위가 좁으면 가용 주소가 더 적고 반복이 더 잦을 수도 있습니다.

모바일 모뎀 다시 연결

일부 모바일 프록시 서비스는 모뎀의 셀룰러 데이터 연결을 끊었다가 다시 수립하는 방식으로 순환합니다. 이 과정에서 해당 연결의 트래픽이 일시 중지될 수 있습니다. 공인 주소는 이동통신사가 결정하므로 다시 연결해도 같은 공인 IP를 받을 수 있습니다.

다른 모바일 서비스는 풀에서 사용 가능한 다른 기기를 선택합니다. 두 방식 모두 모바일 프록시 순환이지만 진행 중인 작업에 미치는 영향은 다를 수 있습니다. 모바일 순환이라는 말만으로는 어떤 방식을 사용하는지 알 수 없습니다.

누가 전환을 제어하는가?

순환 게이트웨이에서는 제공업체가 요청한 모드에 따라 출구를 선택합니다. 서비스가 출구 주소를 관리하는 동안 애플리케이션은 설정에 같은 게이트웨이를 유지할 수 있습니다.

애플리케이션이 고정 프록시 목록을 직접 순환할 수도 있습니다. 예를 들어 첫 작업에 첫 주소를, 다음 작업에 두 번째 주소를 사용하는 식으로 목록을 따라 진행할 수 있습니다. 순서대로 또는 무작위로 선택하고, 독립적인 요청마다 전환하거나 작업이 끝날 때까지 프록시를 유지할 수 있습니다.

따라서 고정 데이터센터 또는 ISP 프록시 목록으로도 순환 작업 방식을 구성할 수 있습니다. 각 프록시 자체의 IP는 고정된 채로, 다음 연결을 어느 프록시로 전달할지 소프트웨어가 바꿉니다. 작업별 주소 할당을 직접 제어하고 싶을 때 유용합니다.

구독에서 구매한 주소를 교체하는 것은 별도의 작업입니다. 예정된 목록 갱신은 접근할 수 있는 IP 집합을 바꿉니다. 애플리케이션이 작업 중 그 주소들 사이를 자동으로 전환하게 하지는 않습니다.

작업에 맞춰 변경 시점 선택

먼저 어떤 동작들이 같은 출구를 유지해야 하는지 파악하세요. 그다음 요청이나 작업이 다른 IP를 사용할 수 있는 지점에 변경을 배치하세요.

작업적합한 변경 시점이유
서로 독립적인 공개 상품 페이지 수집요청마다 또는 새 대상 연결마다각 결과를 따로 선택한 출구로 가져올 수 있습니다.
정해진 기간 안에 여러 관련 검사 실행검사 전체를 포함하는 시간 기반 할당할당이 유효한 동안 요청들이 출구를 함께 사용할 수 있습니다.
소요 시간이 달라지는 일련의 작업 완료필요할 때, 완료 후서로 묶인 단계가 언제 끝났는지 애플리케이션이 알고 있습니다.

장시간 전송에서는 짧은 순환 간격보다 기존 연결을 어떻게 처리하는지가 더 중요합니다. 여러 작업을 동시에 실행할 때는 순환 제어가 각 작업에 따로 적용되는지, 공유 자원에 적용되는지 확인하세요.

IP를 바꿔도 브라우저 쿠키나 계정 데이터는 지워지지 않습니다. 웹사이트는 여전히 요청들을 같은 세션이나 계정과 연결할 수 있습니다. 순환은 트래픽을 여러 출구에 분산할 뿐, 모든 제한을 초기화하거나 요청의 성공을 보장하지 않습니다.

전체 작업을 실행하기 전에 작은 테스트로 선택한 방식을 확인하세요. 새 연결의 출구 IP와 시각을 기록하고, 예상되는 타이머 경계나 변경 명령 이후에 검사를 반복하세요. 열려 있는 연결이 유지되는지도 확인하세요. 이러한 관찰로 실제 전환이 작업에 적합한지 알 수 있습니다. IP가 반복된다는 사실만으로 순환 기능이 고장났다고 판단할 수는 없습니다.

지식 베이스로 돌아가기