Patchright 프록시 설정: 시작, 컨텍스트, 인증 및 Docker
Patchright는 Playwright가 브라우저를 시작하기 전에 CDP 누출을 패치합니다. IP 평판에는 영향을 주지 않으며, 권장되는 은밀한 설정은 프록시 회전 방식을 조용히 변경합니다.
Patchright는 Playwright의 패치된 탐지되지 않는 빌드로, 드롭인 대체품으로 작동합니다: import를 변경하고 코드는 그대로 유지하세요. 패치는 브라우저 프로세스가 시작되기 전에 적용되며, 사이트가 Playwright 세션을 첫 몇 밀리초 내에 지문을 채취할 수 있게 하는 자동화 플래그와 Chrome DevTools Protocol 호출을 제거합니다. 네트워크는 건드리지 않습니다. 모든 Patchright 프록시 질문은 이 분할로 돌아오며, README가 묻어둔 한 가지 세부 사항으로 돌아갑니다: 최대 은밀성을 위한 프로젝트 권장 설정은 지속적인 컨텍스트로, 이는 프록시 회전 방식을 조용히 변경합니다. 이것은 프록시 중심의 가이드입니다 — 시작 대 컨텍스트, 인증된 게이트웨이, Docker, 그리고 한계에 대한 솔직한 설명.
설치 및 드롭인 프록시
Patchright는 Python, Node 및 .NET용으로 제공되며, Chromium만 패치합니다 — Firefox와 WebKit은 명시적으로 지원되지 않습니다. 설치하고 번들된 Chromium 대신 실제 Google Chrome을 가져오세요. 프로젝트는 은밀성을 위해 이를 권장합니다:
pip install patchright
patchright install chrome
# Node: npm i patchright && npx patchright install chrome프록시 API는 Playwright의 것과 동일하며, 변경되지 않았습니다. 프록시는 Patchright가 의도적으로 건드리지 않는 몇 가지 중 하나입니다. 자격 증명은 서버 URL 내부가 아닌 전용 필드에 들어가야 합니다 — 이는 Selenium이나 원시 Puppeteer와 달리 여기서는 인증된 프록시에 확장 쉼이 필요하지 않은 이유입니다:
from patchright.sync_api import sync_playwright
PROXY = {
"server": "http://gate.quantumproxies.io:PORT",
"username": "USER",
"password": "PASS",
}
with sync_playwright() as p:
browser = p.chromium.launch(channel="chrome", proxy=PROXY)
page = browser.new_page()
page.goto("https://httpbin.org/ip")
print(page.text_content("body")) # the exit IP
browser.close()Patchright가 프록시를 지원하느냐에 대한 전체 답변입니다: 예, 업스트림 Playwright와 동일하게, bypass 목록과 루프백 주소가 프록시를 완전히 건너뛰는 Chromium의 특이점을 포함합니다 — 따라서 로컬 모의 서버에 대해 테스트할 때는 항상 프록시가 무시되는 것처럼 보일 것입니다. 기본 모델에 익숙하지 않다면, 우리의 Playwright 프록시 통합 가이드가 기본 동작을 다루고 있으며, 탐지 방지 프레임워크 프록시 맵은 어떤 스택이 자격 증명을 본래적으로 수용하는지 비교합니다.
컨텍스트별 프록시 및 글로벌 스텁
컨텍스트는 저렴한 회전 단위입니다: 별도의 쿠키, 저장소 및 캐시가 있으며, 브라우저 시작에 걸리는 몇 초 대신 몇 밀리초 만에 생성됩니다. 각 컨텍스트는 자체 proxy 옵션을 가지므로, 하나의 프로세스가 미국 신원과 독일 신원을 동시에 가질 수 있습니다. 여기서 사람들을 혼란스럽게 만드는 Playwright의 한 가지 문서화된 문제점이 있습니다 — 브라우저는 Chromium에서 컨텍스트별 프록시가 작동하려면 글로벌 프록시로 시작해야 합니다. 모든 컨텍스트가 이를 덮어쓰면 글로벌 값은 절대 사용되지 않으며, 아무 자리 표시자 문자열로도 설정할 수 있습니다:
const { chromium } = require('patchright');
(async () => {
// the global proxy is never used — it only enables the per-context option
const browser = await chromium.launch({
channel: 'chrome',
proxy: { server: 'http://per-context' },
});
for (const job of jobs) {
const context = await browser.newContext({
proxy: {
server: 'http://gate.quantumproxies.io:PORT',
username: 'USER-country-' + job.country, // geo in the username
password: 'PASS',
},
});
const page = await context.newPage();
try {
await page.goto(job.url, { timeout: 30000 });
// ...extract...
} finally {
await context.close(); // burns the cookies with the exit
}
}
await browser.close();
})();회전 게이트웨이에 지시하면, 각 컨텍스트는 9천만 개 이상의 주거용 풀에서 다른 주소로 나가며, 당신 쪽에서 목록 관리는 없습니다 — 이것이 서버 측에서 회전 프록시가 하는 일입니다. 그 코드 조각에서 지리 및 세션 제어가 어디에 있는지 주목하세요: 사용자 이름에 있으며, 사용자 정의 헤더가 아닙니다. 이는 Patchright에서 일반 Playwright보다 더 중요합니다, 왜냐하면 프로젝트 자체의 지침은 사용자 정의 헤더와 사용자 에이전트 오버라이드를 피하는 것이기 때문입니다, 주입된 값 자체가 탐지 표면이기 때문입니다. 사용자 이름 매개변수 제어는 브라우저의 요청 모양을 그대로 유지합니다.
지속적인 컨텍스트의 트레이드오프
Patchright의 권장 은밀성 구성은 launch()가 아닙니다. 그것은 launch_persistent_context()로, 실제 Chrome 채널, 사용자 데이터 디렉토리, 뷰포트 오버라이드 없음 및 헤드 모드입니다 — 그리고 명시적으로 사용자 정의 헤더나 스푸핑된 사용자 에이전트 없이. 그 설정은 또한 도전이 제공하는 모든 클리어런스 쿠키를 지속시키므로, 해결된 도전은 실행 간에 재사용 가능합니다. 프록시 결과는 구조적입니다: 지속적인 컨텍스트는 컨텍스트입니다. 두 번째 프록시를 걸 수 있는 newContext()가 없으므로, 하나의 프로세스는 하나의 종료 신원과 같습니다.
from patchright.sync_api import sync_playwright
with sync_playwright() as p:
ctx = p.chromium.launch_persistent_context(
user_data_dir="profiles/it-01", # one profile per identity
channel="chrome",
headless=False,
no_viewport=True,
proxy={
"server": "http://gate.quantumproxies.io:PORT",
"username": "USER-country-it-session-it01", # sticky, pinned to the profile
"password": "PASS",
},
# do NOT pass user_agent or extra_http_headers here
)
page = ctx.new_page()
page.goto("https://example.com")
ctx.close()따라서 회전은 프로세스 수준의 결정이 됩니다: 신원당 하나의 프로필 디렉토리, 고정된 세션 하나가 그것에 고정되며, 컨텍스트 루프 대신 작업자 풀을 사용합니다. 페어링을 안정적으로 유지하세요 — 이탈리아 종료 뒤에 쿠키를 축적한 프로필이 브라질 종료 뒤에 다시 나타나면, 이는 어떤 CDP 패치도 숨길 수 없는 모순입니다. 실용적인 규칙: 디렉토리를 세션 ID로 이름 짓고, 세션을 소진할 때 디렉토리를 삭제하며, 두 종료 간에 프로필을 공유하지 마세요.
프록시 뒤에서 Docker에서 Patchright 실행하기
은밀한 브라우저를 컨테이너화하는 데 두 가지 함정이 있으며, 둘 다 프록시 결과를 가집니다. 첫 번째는 --no-sandbox입니다: 루트로 Chrome이 시작을 거부할 때의 일반적인 수정이며, 안티봇 벤더가 기쁘게 읽는 플래그입니다. 대신 비루트 사용자로 실행하세요. 두 번째는 헤드리스 모드입니다 — 프로젝트는 헤드 모드를 권장하므로, 헤드리스 스위치를 사용하기보다는 가상 디스플레이를 사용하세요:
# Dockerfile
FROM python:3.12-slim
RUN apt-get update && apt-get install -y --no-install-recommends \
xvfb ca-certificates && rm -rf /var/lib/apt/lists/*
RUN pip install --no-cache-dir patchright \
&& patchright install --with-deps chrome
RUN useradd -m app
USER app
WORKDIR /home/app
COPY --chown=app:app scrape.py .
# headed under a virtual display: no --no-sandbox, no HeadlessChrome tell
CMD ["xvfb-run", "-a", "python", "scrape.py"]
# build & run:
# docker build -t patchright-worker .
# docker run --ipc=host --shm-size=1g patchright-worker--ipc=host와 더 큰 /dev/shm는 Playwright 컨테이너 문서에서 직접 가져온, 부하 시 탭 충돌에 대한 표준 Chromium-in-Docker 수정입니다. 프록시 특정 함정 하나: SOCKS5 엔드포인트에 자격 증명을 추가하기 위해 로컬 릴레이를 실행하면, 컨테이너 내부의 127.0.0.1은 호스트가 아닌 컨테이너입니다. 릴레이를 동일한 컨테이너에 넣거나, 호스트를 명시적으로 주소 지정하거나, 공유 네트워크에서 사이드카로 릴레이를 실행하세요. 지속적인 컨텍스트를 사용하는 경우 프로필 디렉토리를 볼륨에 유지하세요, 그렇지 않으면 모든 컨테이너 재시작 시 획득한 클리어런스 쿠키를 버리게 됩니다.
패치가 다루는 것과 절대 다루지 않을 것
정확히 무엇을 구매하고 있는지 아는 것이 가치가 있습니다. Patchright의 주요 수정은 Runtime.enable 누출입니다 — 도메인을 활성화하지 않고 게임을 드러내는 대신, 격리된 실행 컨텍스트에서 JavaScript를 실행합니다. Console.enable을 닫기 위해 Console API를 비활성화합니다 (따라서 page.on("console") 로깅이 사라지며, 이는 프록시 실패를 디버깅할 때 실제 비용입니다). Playwright의 기본 플래그를 다시 작성합니다: --disable-blink-features=AutomationControlled를 추가하고, --enable-automation을 제거하며, --disable-popup-blocking, --disable-component-update, --disable-default-apps 및 --disable-extensions를 다시 추가합니다. 또한 일반 로케이터로 닫힌 그림자 루트에 접근합니다.
그 플래그 목록을 대역폭 항목으로도 읽으세요. 구성 요소 업데이트와 기본 앱을 복원하면 백그라운드에서 본사에 전화하는 브라우저가 됩니다 — 측정된 종료를 통해. 세션의 전송을 측정하고, 확장하기 전에 페이지당 비용을 낮추기 위해 컨텍스트에서 이미지, 글꼴 및 미디어 리소스 유형을 차단하세요. 이 모든 것은 다른 벽을 건드리지 않습니다: 소각된 데이터센터 IP에서 패치된 브라우저는 여전히 소각된 IP이며, 요청은 이 모든 영리함이 평가되기 전에 평판으로 거부됩니다. 패치가 실패했다고 결론 내리기 전에 무료 IP 품질 검사기로 주소를 확인하고, 브라우저 아래에 주거용 프록시를 두어 두 계층이 다른 문제를 해결하도록 하세요.
자주 묻는 질문
Patchright에서 프록시를 어떻게 설정하나요?
Playwright에서와 정확히 동일합니다: proxy={"server": "http://host:port", "username": "USER", "password": "PASS"}를 chromium.launch(), launch_persistent_context() 또는 new_context()에 전달하세요. Patchright는 프록시 레이어를 패치하지 않으므로, 모든 업스트림 동작 — 우회 목록, 루프백 예외 — 이 변경 없이 적용됩니다.
Patchright는 SOCKS5 프록시 인증을 지원하나요?
아니요, 이는 Patchright의 제한이 아닌 Chromium의 제한입니다: Chromium은 SOCKS 자격 증명에 대한 메커니즘이 없으므로, 인증된 SOCKS5 엔드포인트는 실패합니다. 동일한 게이트웨이의 HTTP 포트를 사용자 이름 및 비밀번호 필드와 함께 사용하거나, IP 화이트리스트로 인증하고 SOCKS5 스킴을 유지하세요 — 모든 QuantumProxies 플랜은 사용자:비밀번호의 대안으로 화이트리스트를 지원합니다. 전체 우회 세트는 우리의 Playwright SOCKS5 인증 가이드에 있으며, 여기서 변경 없이 적용됩니다.
Patchright는 컨텍스트별로 다른 프록시를 사용할 수 있나요?
예, 브라우저를 글로벌 프록시 값 — 심지어 자리 표시자라도 — 로 시작한 경우 가능합니다, 왜냐하면 Chromium은 시작 시 하나가 있을 때만 컨텍스트별 프록시를 활성화하기 때문입니다. 예외는 Patchright가 은밀성을 위해 권장하는 지속적인 컨텍스트 설정입니다: 이는 단일 컨텍스트를 제공하므로, 회전은 자체 프로필 디렉토리가 있는 별도의 프로세스를 의미합니다.
Patchright는 Chromium 전용인가요?
예. 프로젝트는 명확히 Chromium 기반 브라우저만 패치된다고 명시합니다; Firefox와 WebKit은 지원되지 않습니다. 프록시 종료에서 파생된 지리와 함께 Firefox 엔진 은밀성이 필요하다면, 이는 다른 도구입니다 — 우리의 Camoufox 프록시 및 geoip 가이드를 참조하세요.
Patchright를 사용해도 여전히 차단되나요?
어려운 대상에서는 예. 독립적인 테스트는 헤드리스 모드가 여전히 HeadlessChrome 표시를 누출하고, 패치된 브라우저가 도달하지만 해결할 수 없는 도전 페이지를 보여줍니다. 패치는 저렴한 자동화 검사를 닫습니다; IP 평판, TLS 지문 및 도전 해결은 별도의 문제로, 별도의 답변이 필요합니다.
Patchright를 있는 그대로 취급하세요: Playwright의 한 줄도 다시 작성하지 않고 제공되는 특정 누출 클래스에 대한 매우 좋은 수정입니다. 신원이 중요한 곳에서 깨끗하고 고정된 종료와 쌍을 이루고, 실행 전에 검증된 종료와 함께 사용하세요 — 그러면 남은 실패는 실제로 대상에 관한 것이지, 설정에 관한 것이 아닙니다. 이것은 기술적 지침이며, 법적 조언이 아닙니다: 법과 사이트의 약관 내에서 자동화하세요.