프록시 풀을 위한 건강 체크: 15분 만에 모니터링 설정하기

```html

많은 프록시를 사용하여 마켓플레이스를 크롤링하거나 여러 소셜 미디어 계정을 관리하거나 광고를 실행하는 경우, 갑자기 일부 프록시가 작동하지 않게 되어 작업이 중단되는 문제를 알고 계실 것입니다. 프록시 풀의 Health check(작동 상태 확인)는 이 문제를 자동으로 해결합니다: 시스템이 각 IP를 확인하고 작동하지 않는 IP를 제외하며 안정적인 연결만 사용합니다.

이 가이드에서는 프록시 풀에 대한 자동 Health check를 설정하는 방법을 살펴보겠습니다: 단순한 가용성 확인부터 고급 모니터링 및 고장난 프록시 교체까지. Wildberries 크롤링부터 Facebook Ads의 멀티 계정 관리까지 모든 작업에 적합합니다.

프록시의 Health check란 무엇이며 왜 필요한가

Health check(작동 상태 확인)는 프록시 풀의 자동 모니터링 시스템으로, 정기적으로 각 IP 주소의 가용성, 속도 및 작동 상태를 확인합니다. 수십 개 또는 수백 개의 프록시를 사용할 때 일부는 불가피하게 작동하지 않게 됩니다: 유효 기간이 만료되거나, IP가 차단되거나, 제공자가 접근을 차단하거나, 단순히 속도가 떨어질 수 있습니다.

Health check가 없으면 문제를 알게 되는 것은 작업이 오류로 중단될 때입니다: 파서가 데이터를 수집하지 못하거나, 계정이 작동하지 않는 프록시로 인해 차단되거나, 광고가 실행되지 않습니다. 설정된 Health check는 시스템이 자동으로 고장난 프록시를 회전에서 제외하고 안정적인 연결만 사용하도록 합니다.

Health check의 필요성:

작동의 안정성: 작업이 중단되기 전에 작동하지 않는 프록시를 제외합니다.
시간 절약: 각 IP를 수동으로 확인하고 오류의 원인을 찾을 필요가 없습니다.
계정의 안전성: 느리거나 불안정한 프록시는 플랫폼의 의심을 불러일으킬 수 있습니다.
비용 최적화: 작동하는 프록시에 대해서만 비용을 지불하고 전체 풀에 대해서는 지불하지 않습니다.

비즈니스 작업에 있어 Health check는 특히 중요합니다: Instagram에서 30개의 고객 계정을 운영하거나 Ozon에서 경쟁자의 가격을 크롤링하거나 Facebook Ads에서 광고를 실행하는 경우, 작동하지 않는 프록시로 인해 작업이 중단되면 금전적 손실과 평판에 타격을 줄 수 있습니다.

프록시 작동 상태 확인 방법

프록시를 확인하는 방법에는 여러 수준이 있습니다: 단순한 가용성 확인부터 익명성과 속도에 대한 심층 분석까지. 방법의 선택은 작업의 필요에 따라 다릅니다: 크롤링에는 기본 확인이 충분하고, 소셜 미디어의 멀티 계정 관리에는 지리적 위치 및 익명성 확인이 필요합니다.

1. 기본 가용성 확인 (Ping Check)

가장 간단한 방법은 프록시를 통해 테스트 서버에 HTTP 요청을 보내고 응답을 받았는지 확인하는 것입니다. 일반적으로 httpbin.org, ip-api.com과 같은 공개 서비스를 사용하거나 자체 테스트 서버를 사용합니다.

확인되는 사항: 프록시가 요청에 응답하는지 여부(상태 200 OK). 이는 완전히 작동하지 않는 IP를 걸러내는 최소한의 확인입니다.

충분한 경우: 공개 데이터 크롤링, 엄격한 보호가 없는 사이트에서 정보 수집, 확인 속도가 중요한 대량 작업.

2. 응답 속도 확인 (Latency Check)

프록시의 응답 시간을 측정합니다 — 요청을 보낸 후 응답을 받기까지 걸리는 밀리초입니다. 느린 프록시(3-5초 이상)는 타임아웃과 플랫폼의 의심을 초래할 수 있습니다.

확인되는 사항: 응답 시간(latency) 및 속도의 안정성. latency가 5000ms를 초과하는 프록시는 일반적으로 풀에서 제외됩니다.

중요한 경우: 소셜 미디어 작업(Instagram, TikTok), 광고 계정(Facebook Ads, Google Ads), 페이지 로딩 속도가 중요한 작업.

3. 지리적 위치 및 IP 평판 확인

IP가 명시된 국가 및 도시와 일치하는지, IP의 평판(블랙리스트에 올라 있지 않거나 스팸에 사용되지 않는지)을 확인합니다. 레지던셜 프록시의 경우 이는 매우 중요합니다 — 플랫폼은 지리적 위치와 계정 데이터의 일치를 확인합니다.

확인되는 사항: IP의 국가 및 도시, 제공자, 스팸 데이터베이스(DNSBL, Spamhaus) 내 존재 여부, 연결 유형(residential/datacenter).

중요한 경우: 소셜 미디어의 멀티 계정 관리, 트래픽 중재, 특정 도시와 연결된 계정 작업(예: Avito에 광고 게시).

4. 익명성 확인 (Anonymity Level)

프록시의 익명성 수준을 결정합니다 — 실제 IP를 드러내는 헤더(X-Forwarded-For, Via)를 전달하는지 여부. 프록시는 세 가지 유형이 있습니다: transparent(투명한, 실제 IP를 전달), anonymous(IP를 숨기지만 프록시임을 표시), elite(완전히 익명).

확인되는 사항: X-Forwarded-For, X-Real-IP, Via, Proxy-Connection 헤더의 존재. 비즈니스 작업에는 오직 elite 프록시만 필요합니다.

필수인 경우: 강력한 안티프로드 보호가 있는 플랫폼(Facebook, Google, TikTok)에서 작업할 때, 멀티 계정 관리, 트래픽 중재.

확인 방법	확인하는 사항	어떤 작업에 적합한가
Ping Check	가용성 (200 OK)	크롤링, 대량 데이터 수집
Latency Check	응답 속도	소셜 미디어, 광고 계정
Geo Check	지리적 위치, IP 평판	멀티 계정 관리, 지역 작업
Anonymity Check	익명성 수준	트래픽 중재, 안티프로드 플랫폼

Health check의 기본 설정: 가용성 확인

각 프록시의 가용성을 확인하는 간단한 Health check 설정부터 시작하겠습니다. 이 방법은 대부분의 작업에 적합하며 설정하는 데 10-15분이 소요됩니다.

1단계: 프록시 목록 준비

IP:PORT:USER:PASS 또는 http://user:pass@ip:port 형식으로 프록시가 포함된 파일을 만듭니다. 각 프록시는 새 줄에 작성합니다.

proxies.txt 파일 예시:

192.168.1.100:8080:user1:pass1
192.168.1.101:8080:user2:pass2
192.168.1.102:8080:user3:pass3

2단계: 테스트 URL 선택

가용성을 확인하기 위해 간단한 응답을 반환하는 안정적인 서버가 필요합니다. 인기 있는 옵션은 다음과 같습니다:

httpbin.org/ip — 프록시의 IP 주소를 JSON 형식으로 반환합니다.
ip-api.com/json — IP와 지리적 위치를 반환합니다.
icanhazip.com — IP만 반환합니다(가장 빠름).
자신의 서버 — 특정 사이트에 대한 접근을 확인해야 하는 경우.

기본 확인을 위해 httpbin.org/ip가 충분합니다 — 안정적이며 구조화된 응답을 반환합니다.

3단계: 확인 스크립트 설정

프록시 목록을 읽고 각 프록시를 통해 요청을 보내고 응답 상태를 확인하는 간단한 스크립트를 만듭니다. 다음은 Python(이러한 작업에 가장 인기 있는 언어)의 예입니다:

import requests
from concurrent.futures import ThreadPoolExecutor
import time

def check_proxy(proxy_line):
    """프록시 하나 확인하기"""
    try:
        # 프록시 문자열 파싱
        parts = proxy_line.strip().split(':')
        proxy_url = f"http://{parts[2]}:{parts[3]}@{parts[0]}:{parts[1]}"
        
        proxies = {
            'http': proxy_url,
            'https': proxy_url
        }
        
        # 10초 타임아웃으로 요청 전송
        start_time = time.time()
        response = requests.get('http://httpbin.org/ip', 
                              proxies=proxies, 
                              timeout=10)
        latency = (time.time() - start_time) * 1000  # 밀리초로 변환
        
        if response.status_code == 200:
            return {
                'proxy': proxy_line,
                'status': 'working',
                'latency': round(latency, 2),
                'ip': response.json().get('origin')
            }
    except Exception as e:
        return {
            'proxy': proxy_line,
            'status': 'failed',
            'error': str(e)
        }

# 프록시 파일 읽기
with open('proxies.txt', 'r') as f:
    proxies = f.readlines()

# 모든 프록시를 병렬로 확인 (최대 20개 동시)
with ThreadPoolExecutor(max_workers=20) as executor:
    results = list(executor.map(check_proxy, proxies))

# 작동하는 프록시 저장
working_proxies = [r for r in results if r and r['status'] == 'working']

with open('working_proxies.txt', 'w') as f:
    for proxy in working_proxies:
        f.write(proxy['proxy'])
        
print(f"확인된 프록시 수: {len(proxies)}")
print(f"작동하는 프록시 수: {len(working_proxies)}")
print(f"작동하지 않는 프록시 수: {len(proxies) - len(working_proxies)}")

이 스크립트는 모든 프록시를 병렬로 확인하여(20개 동시) 프로세스를 수십 배 빠르게 합니다. 결과는 작동하는 프록시만 포함된 working_proxies.txt 파일입니다.

4단계: 확인 자동화

Health check가 지속적으로 작동하도록 스크립트를 일정에 따라 자동으로 실행하도록 설정합니다:

Linux/Mac (cron):

# 30분마다 확인
*/30 * * * * /usr/bin/python3 /path/to/check_proxies.py

Windows (작업 스케줄러):

"작업 스케줄러" 열기
새 작업 만들기 → 트리거: 30분마다
작업: python.exe를 실행하고 스크립트 경로 지정

⚠️ 중요:

프록시를 너무 자주 확인하지 마세요(15분 이내) — 이는 테스트 서비스에 부담을 주고 차단될 수 있습니다. 최적의 빈도: 안정적인 프록시의 경우 30-60분마다, 가용성이 중요한 작업의 경우 10-15분마다.

고급 모니터링: 속도, 지리적 위치, 익명성

비즈니스 작업에는 기본 가용성 확인만으로는 부족합니다 — 속도, 지리적 위치 및 익명성 수준을 모니터링해야 합니다. 이는 특히 소셜 미디어의 멀티 계정 관리 및 트래픽 중재에서 중요합니다. 플랫폼은 프록시를 엄격하게 검사합니다.

속도 및 안정성 확인

느린 프록시(latency가 3-5초 이상)는 플랫폼의 의심을 초래할 수 있습니다: Instagram과 Facebook은 페이지 로딩 시간을 추적하며 느린 연결은 프록시 사용의 징후입니다. 또한 느린 프록시는 작업 속도를 저하시킬 수 있으며 타임아웃을 초래할 수 있습니다.

확인해야 할 사항:

Latency(응답 시간): 요청에서 응답까지의 평균 시간. 기준: 레지던셜 프록시는 1000ms 이하, 데이터 센터는 300ms 이하.
다운로드 속도: 프록시를 통해 초당 몇 킬로바이트가 다운로드되는지. 기준: 최소 500Kbps.
안정성: 3-5개의 연속 요청 확인 — latency는 크게 변동하지 않아야 합니다(변동폭이 50% 이상이면 나쁜 신호).

속도 확인의 예:

def check_proxy_speed(proxy_url):
    """속도 및 안정성 확인"""
    latencies = []
    
    # 안정성 확인을 위해 5개의 요청 수행
    for i in range(5):
        try:
            start = time.time()
            response = requests.get('http://httpbin.org/ip',
                                  proxies={'http': proxy_url, 'https': proxy_url},
                                  timeout=10)
            latency = (time.time() - start) * 1000
            latencies.append(latency)
            time.sleep(0.5)  # 요청 간 대기
        except:
            return None
    
    avg_latency = sum(latencies) / len(latencies)
    max_latency = max(latencies)
    min_latency = min(latencies)
    stability = (max_latency - min_latency) / avg_latency * 100
    
    return {
        'avg_latency': round(avg_latency, 2),
        'stability': round(stability, 2),  # 변동률 %
        'status': 'good' if avg_latency < 3000 and stability < 50 else 'slow'
    }

지리적 위치 확인

멀티 계정 관리에서는 프록시의 지리적 위치가 계정 데이터와 일치하는 것이 중요합니다. 만약 모스크바 회사의 계정을 블라디보스토크의 프록시를 통해 운영한다면, 이는 플랫폼에 대한 적신호입니다. ip-api.com 서비스를 사용하여 지리적 위치를 확인하세요:

def check_proxy_geo(proxy_url):
    """프록시의 지리적 위치 확인"""
    try:
        response = requests.get('http://ip-api.com/json',
                              proxies={'http': proxy_url, 'https': proxy_url},
                              timeout=10)
        data = response.json()
        
        return {
            'ip': data.get('query'),
            'country': data.get('country'),
            'city': data.get('city'),
            'isp': data.get('isp'),
            'proxy_type': data.get('proxy'),  # 프록시가 발견되면 True
            'mobile': data.get('mobile')  # 모바일 IP의 경우 True
        }
    except:
        return None

각 프록시의 지리적 위치 데이터를 저장하고 작업 분배 시 사용하세요: 모스크바의 계정은 모스크바 프록시를 통해, 지역 광고는 해당 도시의 프록시를 통해 진행합니다.

익명성 확인

프록시는 세 가지 익명성 수준이 있습니다: transparent(투명), anonymous(익명), elite(엘리트). Facebook, Instagram, TikTok 및 기타 안티프로드 보호가 있는 플랫폼에서 작업할 때는 오직 elite 프록시만 필요합니다 — 이들은 프록시 사용을 드러내는 헤더를 전달하지 않습니다.

확인해야 할 사항:

X-Forwarded-For, X-Real-IP, Via 헤더 — 존재하지 않아야 합니다.
응답의 IP는 프록시의 IP와 일치해야 하며(실제 IP가 아님),
User-Agent는 변경 없이 전달되어야 합니다.

def check_proxy_anonymity(proxy_url):
    """익명성 수준 확인"""
    try:
        response = requests.get('http://httpbin.org/headers',
                              proxies={'http': proxy_url, 'https': proxy_url},
                              timeout=10)
        headers = response.json()['headers']
        
        # 프록시를 드러내는 헤더의 존재 확인
        proxy_headers = ['X-Forwarded-For', 'X-Real-Ip', 'Via', 'Proxy-Connection']
        detected_headers = [h for h in proxy_headers if h in headers]
        
        if len(detected_headers) == 0:
            return 'elite'  # 완전히 익명
        elif 'X-Forwarded-For' not in headers:
            return 'anonymous'  # IP를 숨기지만 프록시임을 표시
        else:
            return 'transparent'  # 실제 IP를 전달
    except:
        return None

비즈니스 작업에는 오직 elite 프록시만 사용하세요. 모바일 프록시는 기본적으로 elite 수준을 가지며, 실제 모바일 운영자의 IP를 사용합니다.

자동 회전: 고장난 프록시 교체

Health check는 단순히 프록시를 확인하는 것이 아니라, 작동하지 않는 프록시를 자동으로 교체할 때 진정으로 유용해집니다. 이는 지속적인 작업에 필수적입니다: 마켓플레이스 크롤링, 가격 모니터링, 소셜 미디어 자동 게시.

전략 1: 우선 순위가 있는 풀

두 개의 프록시 목록을 만듭니다: 기본(작동 중) 및 백업(예비). Health check는 기본 풀을 지속적으로 확인하고, 작동하지 않는 프록시가 발견되면 백업 풀에서 프록시로 교체합니다.

작동 방식:

Health check는 기본 풀의 모든 프록시를 30분마다 확인합니다.
작동하지 않는 프록시는 "격리" 목록으로 이동합니다.
백업 풀에서 작동하는 프록시를 가져와 기본 풀에 추가합니다.
2-4시간 후, 격리된 프록시를 다시 확인합니다 — 작동하면 백업으로 돌아갑니다.

구현 예시:

import json
from datetime import datetime, timedelta

class ProxyPool:
    def __init__(self):
        self.working = []  # 기본 풀
        self.backup = []   # 백업 풀
        self.quarantine = {}  # {proxy: 격리된 시간}
    
    def check_and_rotate(self):
        """프록시 확인 및 회전"""
        failed_proxies = []
        
        # 기본 풀 확인
        for proxy in self.working:
            if not self.is_proxy_working(proxy):
                failed_proxies.append(proxy)
                self.quarantine[proxy] = datetime.now()
        
        # 작동하지 않는 프록시 제거
        self.working = [p for p in self.working if p not in failed_proxies]
        
        # 필요한 만큼 백업에서 추가
        needed = len(failed_proxies)
        for i in range(needed):
            if len(self.backup) > 0:
                new_proxy = self.backup.pop(0)
                if self.is_proxy_working(new_proxy):
                    self.working.append(new_proxy)
        
        # 격리 확인 — 격리된 프록시가 4시간 이상 경과하면 확인
        now = datetime.now()
        for proxy, quarantine_time in list(self.quarantine.items()):
            if now - quarantine_time > timedelta(hours=4):
                if self.is_proxy_working(proxy):
                    self.backup.append(proxy)
                del self.quarantine[proxy]
        
        self.save_state()
    
    def save_state(self):
        """풀 상태 저장"""
        state = {
            'working': self.working,
            'backup': self.backup,
            'quarantine': {k: v.isoformat() for k, v in self.quarantine.items()}
        }
        with open('proxy_pool_state.json', 'w') as f:
            json.dump(state, f)

전략 2: 예외가 있는 라운드 로빈

더 간단한 접근 방식: 모든 프록시를 순서대로 사용하되, 오류가 발생하면 30-60분 동안 프록시를 회전에서 제외합니다. 속도가 중요하고 완벽한 안정성이 필요하지 않은 작업에 적합합니다.

작동 방식:

프록시는 순서대로 선택됩니다: 1, 2, 3, 4, 1, 2, 3, 4...
프록시가 오류를 반환하면 30분 동안 제외됩니다.
30분 후, 프록시는 자동으로 회전으로 돌아옵니다.
프록시가 연속으로 3번 실패하면 4시간 동안 제외됩니다.

이 방법은 크롤링 및 대량 작업에 적합하며, 몇 개의 요청을 건너뛰어도 큰 문제가 없습니다.

전략 3: 메트릭에 따른 가중 회전

고급 접근 방식: 각 프록시에는 메트릭(속도, 안정성, 요청 성공률)에 따라 "가중치"가 부여됩니다. 높은 가중치의 프록시는 더 자주 사용되고, 낮은 가중치의 프록시는 덜 사용됩니다. 이는 멀티 계정 관리 및 트래픽 중재와 같은 중요한 작업에 적합합니다.

가중치 공식:

weight = (success_rate * 0.5) + (speed_score * 0.3) + (uptime * 0.2)

여기서:
- success_rate: 지난 1시간 동안의 성공적인 요청 비율 (0-100)
- speed_score: 100 - (latency / 50) — 빠를수록 높음
- uptime: 지난 24시간 동안 프록시가 사용 가능했던 시간의 비율

가중치가 70 이상인 프록시는 중요한 작업(계정 로그인)에 사용되고, 40-70은 일반 작업에 사용되며, 40 미만은 일시적으로 제외됩니다.

프록시 풀의 Health check를 위한 준비된 도구

자체 스크립트를 작성하고 싶지 않다면 준비된 솔루션을 사용하세요. 많은 솔루션이 웹 인터페이스, API 및 인기 있는 도구와의 통합을 제공합니다.

1. ProxyChecker by Proxy-Store

Windows/Linux용 무료 유틸리티로 그래픽 인터페이스를 제공합니다. 가용성, 속도, 익명성 및 지리적 위치를 확인합니다. HTTP, HTTPS, SOCKS4/5를 지원합니다. 결과를 TXT, CSV, JSON으로 내보낼 수 있습니다.

장점: 간단한 인터페이스, 빠른 확인(1분에 최대 1000 프록시), 국가 및 속도에 따른 필터링.

단점: 자동 회전 없음, 수동으로 실행해야 함.

2. Proxy Scraper & Checker

무료 프록시 자동 수집 및 Health check 기능이 있는 Python 기반 오픈 소스 프로젝트입니다. 실험 및 테스트에 적합하지만 비즈니스에는 적합하지 않습니다(무료 프록시는 불안정함).

장점: 무료, 자동 프록시 수집, 사용자 정의 가능한 확인.

단점: 무료 프록시의 품질이 낮고, 자주 차단됨.

3. Proxy Pool Manager (상업적 솔루션)

Health check, 자동 회전, API, 안티탐지 브라우저(Dolphin Anty, AdsPower, Multilogin)와의 통합을 포함한 프록시 관리의 전체 사이클을 제공하는 유료 서비스입니다. 예: Bright Data Proxy Manager, Smartproxy Dashboard, Oxylabs Proxy Rotator.

장점: 모든 기능이 통합된 솔루션, 24/7 지원, 준비된 통합.

단점: 높은 비용(월 $50부터 시작), 특정 프록시 제공업체에 종속됨.

4. 안티탐지 브라우저 내장 Health check

멀티 계정 관리를 위해 안티탐지 브라우저를 사용하는 경우, 많은 브라우저가 내장된 프록시 확인 기능을 제공합니다:

Dolphin Anty: 프록시를 프로필에 추가할 때 가용성 및 속도 확인
AdsPower: 프로필 실행 전에 프록시 자동 확인
Multilogin: 익명성 확인을 포함한 내장 프록시 테스터
GoLogin: 지리적 위치 및 IP 평판 확인

이러한 도구는 50-100개의 계정으로 작업하는 SMM 전문가 및 트래픽 중재자에게 편리합니다. 대량의 경우 자체 솔루션이 필요합니다.

도구	유형	기능	대상
ProxyChecker	무료 유틸리티	가용성, 속도, 익명성 확인	소규모 비즈니스, 일회성 확인
자체 스크립트	오픈 소스	완전한 사용자 정의, 자동화	개발자, 대규모 풀
Proxy Manager	상업적 SaaS	Health check, 회전, API, 지원	비즈니스, 중요한 작업
안티탐지 브라우저	내장 기능	프로필 실행 시 기본 확인	SMM, 트래픽 중재, 100개 이하의 계정

비즈니스 사용 시나리오

Health check 프록시 풀이 실제 비즈니스 문제를 해결하는 구체적인 사례를 살펴보겠습니다.

사례 1: 마켓플레이스에서 경쟁자 가격 크롤링

작업: Wildberries의 판매자가 500명의 경쟁자의 가격을 2시간마다 크롤링하여 자동으로 자신의 가격을 조정합니다. 50개의 프록시 풀을 사용합니다.

Health check가 없을 때의 문제: 일부 프록시는 100-200개의 요청 후 Wildberries에 의해 차단되어 파서가 오류로 중단되고 데이터가 완전히 수집되지 않습니다. 매 2-3일마다 수동으로 프록시를 확인하고 교체해야 합니다.

Health check로 해결: 시스템은 30분마다 모든 50개의 프록시를 Wildberries에 요청하여 확인합니다. 작동하지 않는 프록시(상태 403, 429 또는 타임아웃)는 자동으로 20개의 백업 프록시 풀에서 교체됩니다. 파서는 항상 작동하는 프록시만 사용합니다.

결과: 크롤링의 안정성이 70%에서 98%로 증가하고, 수동 작업이 하루 2시간에서 주 10분으로 줄어들었습니다.

사례 2: SMM 에이전시의 멀티 계정 관리

작업: SMM 에이전시는 Dolphin Anty를 통해 고객의 Instagram 계정 80개를 운영합니다. 각 계정은 자신의 프록시에 연결되어 있습니다(1 계정 = 1 프록시).

Health check가 없을 때의 문제: 프록시가 작동하지 않게 되면 매니저는 고객 계정에 로그인할 수 없을 때만 이를 알게 됩니다. 이 시간 동안 Instagram은 "의심스러운 활동"으로 인해 계정을 차단할 수 있습니다(급격한 IP 변경).

Health check로 해결: 시스템은 60분마다 모든 80개의 프록시(가용성 + 지리적 위치)를 확인합니다. 프록시가 응답하지 않으면 매니저는 Telegram으로 알림을 받고, Dolphin Anty에서는 동일한 도시의 백업 프록시로 프로필 설정이 자동으로 업데이트됩니다.

결과: 프록시 문제로 인한 계정 차단 수가 월 5-7회에서 0-1회로 줄어들었습니다. 절감액: ~$500/월(계정 복구 비용).

사례 3: Facebook Ads의 트래픽 중재

작업: 트래픽 중재자는 15개의 Facebook Ads 계정으로 광고를 실행합니다. 각 계정은 미국의 레지던셜 프록시를 사용합니다.

Health check가 없을 때의 문제: Facebook은 IP의 안정성을 엄격하게 검사합니다. 프록시가 "점프"하면(IP가 변경되거나 연결이 끊어지면) 계정이 검토되거나 즉시 차단됩니다. 계정 손실 비용: $200-500(복구 + 캠페인 중단).

Health check로 해결: 15분마다 확인: 가용성, 속도(지연이 안정적이어야 함), 익명성(엘리트 수준). 프록시가 불안정성을 보일 경우(지연 변동이 30% 이상) 회전에서 제외됩니다. 중요한 계정에는 지난 24시간 동안 가동 시간이 99.5% 이상인 프록시만 사용됩니다.

결과: 프록시 문제로 인한 차단 수가 월 2-3회에서 0으로 줄어들었습니다. 캠페인의 안정적인 운영 덕분에 ROI가 15% 증가했습니다.

💡 팁:

중요한 작업(멀티 계정 관리, 트래픽 중재)에는 높은 가동 시간을 가진 레지던셜 프록시를 사용하세요. 데이터 센터보다 비싸지만 안정성과 낮은 차단 위험이 가격 차이를 보상합니다.

Health check 설정 시 자주 발생하는 오류

Health check의 효율성을 떨어뜨리거나 새로운 문제를 일으키는 일반적인 오류를 살펴보겠습니다.

오류 1: 너무 잦은 확인

문제: 1-5분마다 확인하면 프록시와 테스트 서비스에 엄청난 부담이 됩니다. 공개 서비스(httpbin.org, ip-api.com)는 플러딩으로 인해 IP를 차단할 수 있습니다. 또한 잦은 확인은 트래픽을 소모합니다 — 100개의 프록시가 있고 매 분마다 확인하면 하루에 144,000개의 요청이 발생합니다.

해결책: 안정적인 프록시의 경우 30-60분마다 확인하면 충분합니다. 중요한 작업의 경우 15분마다 확인하세요. 잦은 확인이 필요하다면 공개 서비스 대신 자체 테스트 서버를 사용하세요.

오류 2: 가용성만 확인

문제: 프록시가 요청에 응답(상태 200 OK)을 하더라도 느리거나(latency가 10초) 잘못된 지리적 위치를 가질 수 있습니다. 비즈니스 작업에는 이런 프록시가 쓸모없거나 심지어 위험할 수 있습니다.

해결책: 가용성 + 속도 + 지리적 위치 + 익명성을 종합적으로 확인하세요. 멀티 계정 관리에는 지리적 위치가 중요하고, 크롤링에는 속도가 중요하며, 트래픽 중재에는 모두 함께 확인해야 합니다.

오류 3: 격리 시스템 부재

문제: 프록시는 서버 재부팅이나 제공자의 문제로 인해 일시적으로 "다운"될 수 있지만, 1-2시간 후에 다시 작동할 수 있습니다. 이런 프록시를 풀에서 즉시 제거하면 작동하는 IP를 잃게 됩니다.

해결책: 격리 시스템을 사용하세요 — 작동하지 않는 프록시는 제거되지 않고 2-4시간 동안 제외됩니다. 그 후 다시 확인하여 작동하면 풀로 복귀합니다.

오류 4: 안정성 메트릭 무시

문제: 프록시가 작동하더라도 불안정할 수 있습니다 — latency가 500ms에서 5000ms로 변동할 수 있으며, 주기적으로 타임아웃이 발생할 수 있습니다.

```

프록시 풀을 위한 헬스 체크 설정 방법: 15분 만에 자동 모니터링하기