ZennoPoster 및 BAS용 프록시: 2026년 스트림 설정

ZennoPoster와 BAS (Browser Automation Studio)는 러시아어 사용자 환경에서 인기 있는 두 가지 봇 제작기입니다: 이들은 등록, 프로그레싱, 포스팅 및 파싱을 수행합니다. 두 프로토콜 모두 주요 소모품이며, 이와 관련된 오류는 일반적으로 문자열 형식이 아니라 스킴에서 발생합니다: 두 개의 스레드가 하나의 IP에 연결되거나, 등록 중간에 주소가 변경되거나, 브라우저 템플릿이 하룻밤 사이에 수십 기가바이트의 이미지를 다운로드합니다. 2026년 가을까지 이를 관리하는 것이 더 쉬워졌습니다: ZennoPoster 7.9.1 (8월 11일)은 프로젝트에서 각 프로토콜의 트래픽을 계산할 수 있게 되었고, ZennoPoster 7.9.2 (9월 17일)와 BAS 30.8.0 (9월 16일)은 브라우저를 Chromium 152 및 153으로 업데이트했습니다. 아래는 두 프로그램 모두에 대한 "하나의 스레드 - 하나의 IP" 작업 스킴과 작업에 따른 회전 선택 및 청구서가 도착하기 전에 트래픽 계산입니다.

2026년에 변경된 사항과 이것이 프로토콜에 중요한 이유

템플릿이 연초 버전에서 작동하는 경우, 프로토콜과 관련된 일부 문제는 간단한 업데이트로 해결됩니다. ZennoLab과 Bablosoft의 변경 로그에서 프로토콜 작업에 중요한 다섯 가지 사항은 다음과 같습니다:

ZennoPoster 7.9.0 (6월 25일). "이미지 처리 → 이미지 저장 → URL" 블록이 프로토콜을 통해 작동할 수 있게 되었습니다. 이전에는 블록이 프로토콜 없이 이미지에 접근했으며, 템플릿이 실행되는 기계의 IP를 사용하여 조용한 유출이 발생했습니다.
ZennoPoster 7.9.1 (8월 11일). 각 프로토콜에 대한 바이트 단위의 수신 및 송신 트래픽 계산이 추가되었습니다: Chromium 및 ChromiumFromZB 브라우저(웹소켓 포함, 캐시 응답 제외) 및 모든 HTTP 블록 - 일반, 대체 및 TLS에 대해. 코드에서 데이터는 ZennoPoster.ProxyTrafficInfo 객체를 통해 접근할 수 있습니다.
같은 버전에서 지리 데이터 및 시간대의 에뮬레이션이 IPv6 주소를 고려하기 시작했으며, SOCKS5 프로토콜을 사용하는 ZennoBrowser 프로필이 통합에서 시작 시 타임아웃으로 중단되지 않게 되었습니다.
ZennoPoster 7.9.2 (9월 17일). 100개 이상의 작업을 위한 공개 HTTP API, AI 어시스턴트를 위한 세 개의 MCP 서버 및 작업 브라우저를 스스로 관리하는 "AI 에이전트" 블록. 엔진 - Chromium 152.
BAS 30.8.0 (9월 16일). 엔진이 153 버전으로 업데이트되었으며, 텍스트 설명에 따라 스크립트를 생성, 변경 및 테스트하는 Agent 모드와 이중 인증 코드 생성 모듈이 추가되었습니다.

실용적인 결론: 템플릿을 확장하기 전에 최소한 ZennoPoster 7.9.1 및 BAS 30.8.0으로 업데이트하세요. 각 프로토콜에 대한 트래픽 계산은 기가바이트에 대한 지불 시 부족했던 바로 그 것입니다.

1단계. 작업에 맞는 회전 모드 선택

짧은 답변: 계정 작업에는 각 스레드에 대해 별도의 포트를 가진 고정 세션이 필요하며, HTTP 요청으로 파싱할 경우 각 요청마다 새로운 IP가 필요합니다; 계정에 로그인하지 않고 브라우저 파싱을 할 경우에는 짧은 간격의 고정 세션이 필요합니다.

ProxyCove에서는 모드가 포트로 설정됩니다. 포트 824는 각 요청마다 IP를 변경합니다. 포트 10000–20000은 간격 회전으로 작동합니다: 각 포트는 자신의 IP를 제공하고 지정된 시간(1분에서 120분까지) 동안 유지합니다. 간격은 프록시 카드의 회전 설정에서 변경됩니다.

등록, 프로그레싱, 포스팅. 계정에는 전체 사이클 동안 안정적인 주소가 필요합니다. 간격은 한 번의 실행 시간에 여유를 두고 설정하세요: 이메일 확인이 포함된 등록이 20-25분이 걸린다면 40-60분을 선택하세요. 양식 중간에 IP를 변경하는 것은 체크포인트의 일반적인 원인입니다.
GET/POST 블록으로 데이터 수집. 각 요청은 독립적이며 세션을 유지할 필요가 없습니다. 포트 824는 풀에 부하를 분산시키고 하나의 IP에 대한 한계에 부딪힐 확률을 줄입니다.
로그인 없이 브라우저 파싱. 여기서는 각 요청마다 회전하는 것이 해롭습니다. Web Almanac 2025에 따르면, 데스크탑에서의 중앙 페이지는 다양한 리소스에 대해 77개의 요청을 수행하며, 포트 824에서 한 페이지의 일부는 서로 다른 주소에서 전송됩니다. 이는 안티봇 시스템에 비정상적인 행동으로 간주되므로, 1-5분 간격의 고정 포트를 사용하고 페이지 간에 IP를 변경하세요, 페이지 내부가 아니라.

2단계. 프록시 유형 선택

유형은 기가바이트 가격뿐만 아니라 플랫폼이 주소에 어떻게 반응하는지를 결정합니다:

주거용 - 가정용 제공자의 IP. 브라우저 템플릿, 마켓플레이스, SEO 스크래핑 및 중간 강도의 사이트 등록을 위한 기본 선택입니다. ProxyCove에서 주거용 프록시 국가 및 회전 간격 선택은 GB당 $2.70입니다.
모바일 - 통신 제공자의 주소. 하나의 IP를 통해 CGNAT를 통해 여러 실제 가입자가 동시에 인터넷에 접속하므로 소셜 미디어는 이들을 더 조심스럽게 차단합니다. 이는 소셜 미디어 계정 및 엄격한 플랫폼을 위한 선택입니다: 모바일 프록시는 GB당 $3.80입니다.
데이터 센터 - GB당 $1.50, 빠르고 저렴하지만 그 서브넷은 안티봇 시스템에 잘 알려져 있습니다. 이는 로열 사이트 및 API의 HTTP 파싱에 적합하며, 소셜 미디어 계정에는 좋지 않은 선택입니다.

플랫폼이 특정 주소가 아닌 안정적인 지리적 위치를 중요시한다면, 도시 또는 제공자(ASN)에 대한 타겟팅을 포함하세요. IP는 변경되지만 일반 사용자처럼 동일한 도시 또는 네트워크 내에서 유지됩니다. 타겟팅은 더 비쌉니다: 주거용의 경우 GB당 $4.70입니다.

3단계. "하나의 포트 - 하나의 스레드" 목록 준비

ProxyCove 대시보드에서 프록시 카드를 열고 간격 회전을 활성화하세요.
"스레드 수" 필드에 필요한 행 수를 입력하세요. 포트는 별도로 청구되지 않으며, 트래픽에 대해서만 지불하므로 스레드 수의 2-3배 긴 목록을 가져가세요. 이유는 아래에서 설명하겠습니다.
http 또는 socks5 형식을 선택하세요. 대시보드는 10000, 10001, 10002 등의 포트가 포함된 행을 생성합니다: 각 행은 고유한 IP를 가진 개별 세션입니다.
목록을 파일로 저장하세요, 예를 들어 proxies.txt. 행은 다음과 같이 보입니다: socks5://login:[email protected]:10000.

타겟팅이 활성화되면, 국가, 도시 또는 ASN 매개변수가 로그인 뒤에 세미콜론을 통해 추가됩니다. 전체 행을 복사하고 수동으로 수정하지 마세요: 매개변수의 오류는 인증 또는 타겟팅을 깨뜨릴 수 있습니다.

4단계. ZennoPoster: 각 스레드에 대한 고유 프록시

ZennoPoster에서 프록시는 전역적으로, 프로젝트 또는 스레드에 대해 설정할 수 있습니다. 다중 스레드 작업을 위해서는 템플릿 내부의 목록에서 행을 가져오는 것이 가장 안전합니다:

ProjectMaker에 "목록" 블록을 추가하고 "파일에서 로드" 및 "목록 변경 사항을 파일에 저장"을 활성화한 후 proxies.txt의 경로를 지정하세요.
"목록 작업"을 추가하세요: "행 가져오기" → "첫 번째"를 선택하고 "가져온 후 행 삭제" 옵션을 체크하세요. 결과를 변수에 저장하세요, 예를 들어 proxy. 삭제는 두 개의 병렬 스레드가 동일한 포트를 가져가지 않도록 보장합니다.
"브라우저 → 설정 → 프록시 설정"을 추가하고 {-Variable.proxy-}를 전달하세요. 위치 및 시간대 에뮬레이션을 활성화하세요: 브라우저는 프록시 IP를 통해 지리 데이터 및 시간대를 받습니다.
각 HTTP 블록(GET, POST)에서 동일한 프록시를 작성하세요 - 변수 또는 프로젝트 프록시 옵션을 통해. 블록의 프록시 필드가 비어 있으면 서버 IP로 요청이 이루어집니다.
마지막 실행 후 - 성공적인 분기와 오류 분기 모두에서 - 행을 목록의 끝으로 되돌리세요. 그렇지 않으면 목록이 점차 비어지고, 각 실패한 스레드는 포트를 영구적으로 "소모"하게 됩니다.

내장된 ProxyChecker는 공개 목록에 유용하지만, 트래픽에 대한 요금이 있는 게이트웨이의 경우 전체 목록을 정기적으로 확인하는 것은 의미가 없습니다: 각 확인은 지불된 메가바이트를 소모하며, 포트 824에서 다음 요청은 여전히 다른 IP로 전송됩니다. 대규모 실행 전에 몇 개의 행만 확인하면 충분합니다.

5단계. BAS: 프록시 및 Proxy 작업 리소스

프록시 목록이 포함된 "파일" 또는 "URL" 유형의 리소스를 생성하세요 - Bablosoft 문서에서 권장하는 방법으로, 템플릿 사용자가 소스를 직접 선택할 수 있습니다.
리소스 설정에서 한 스레드에 대해 행의 동시 사용을 제한하세요. 여기서 성공 및 실패 사용의 한계와 사용 간 간격을 설정합니다 - 고정 포트의 경우 회전 간격보다 짧지 않게 설정하세요.
스레드의 첫 번째 작업으로, 어떤 페이지를 로드하기 전에 "Proxy"를 설정하고 리소스에서 행을 전달하세요. BAS는 login:password@host:port 및 socks5://login:password@host:port를 포함한 많은 형식을 이해하며, 인증이 있는 HTTP 및 SOCKS5와 함께 작동하고 DNS 요청을 프록시를 통해 전송합니다.
프록시 IP에 따라 지리적 위치 및 시간대 변경을 활성화하세요.
템플릿이 HTTP 클라이언트로 사이트에 접근하는 경우, 해당 클라이언트에도 프록시를 설정하세요: BAS의 HTTP 클라이언트는 브라우저와는 별도의 설정을 가집니다.

BAS에서 두 가지 특징을 고려해야 합니다. 프록시는 스레드를 재시작하지 않고 "Proxy" 작업을 반복하여 변경할 수 있습니다 - 이는 오류로 인해 IP를 변경하는 데 유용합니다. 만약 프록시가 응답하지 않으면, BAS는 스레드를 재시작하고 다음 것을 가져옵니다. 파싱에는 장점이지만, 계정에는 위험이 있습니다: 작업이 다른 IP에서 계속 진행됩니다. "계정 - 포트" 조합을 저장하고 계정을 원래 포트로 되돌리세요.

6단계. 시작 전에 트래픽 계산하기

기가바이트에 대한 요금을 지불할 때 브라우저 템플릿은 스킴의 가장 비싼 부분입니다. Web Almanac 2025에 따르면, 중앙 페이지는 데스크탑에서 2862 KB의 크기를 가지며, 그 중 1058 KB는 이미지입니다. 이러한 페이지의 10,000회 다운로드는 약 28.6 GB이며, 주거용 프록시에서는 약 $77입니다. 이미지 없이 약 18 GB 및 $49입니다. 실제 숫자는 사이트 및 캐시에 따라 다르지만, 대략적인 순서는 이해할 수 있습니다: 이미지는 청구서의 3분의 1 이상을 차지합니다.

BAS. "Request mask deny" 및 "Request mask allow" 작업은 페이지 로드 전에 설정되며, 별표가 있는 마스크를 수용합니다. Bablosoft 문서의 예: *.png, *.jpg 및 *.gif를 금지한 후, 캡차 이미지만 로드되도록 허용합니다.
ZennoPoster. 가장 큰 절약은 브라우저에서 데이터 수집을 GET/POST 블록으로 이동하는 것입니다: 이들은 이미지, 글꼴 및 스크립트를 다운로드하지 않습니다. "트래픽" 창에서 가장 많은 요청이 어떤 것인지 확인할 수 있으며, 7.9.1 버전부터는 각 프로토콜에 대한 양을 ZennoPoster.ProxyTrafficInfo를 통해 코드에서 읽고, 로그에 기록하며, 한계를 초과할 경우 스레드를 중단할 수 있습니다.
소셜 미디어에 주의하세요. 이미지가 없는 페이지는 실제 사용자에게는 드물며, 일부 플랫폼에서는 이것 자체로 비정상적으로 보일 수 있습니다. 계정의 경우 무거운 비디오 및 미디어를 차단하고 이미지는 남겨두는 것이 좋습니다.

대시보드와 자신의 계정을 비교하세요: 거기서 각 프로토콜에 대한 잔액 및 소비 그래프를 볼 수 있습니다. 제공자의 데이터는 지연되어 업데이트되므로, 즉각적인 모니터링은 템플릿 내에서 수행하는 것이 더 편리합니다.

잠재적 문제

실제 IP 유출. 프록시 없이 HTTP 블록, ZennoPoster에서 URL로 이미지를 저장하는 것(7.9.0 이전), WebRTC. 템플릿의 첫 번째 단계에서 IP 및 WebRTC 확인 페이지를 열고 결과를 프록시 주소와 비교하세요 - 이는 차단 문제를 해결하는 것보다 저렴합니다.
세션 중 IP 변경. 회전 간격이 계정 사이클보다 짧으면, 플랫폼은 하나의 양식의 단계 간 주소 점프를 감지합니다. ProxyCove의 최대 간격은 120분입니다; 긴 시나리오는 짧은 세션으로 나누어 프로필을 유지하세요.
하나의 IP에 두 개의 계정. 회전 간격이 만료되지 않은 동안 포트는 이전 주소를 제공합니다. 포트가 즉시 다음 계정에 할당되면, 그 계정은 이전의 IP로 인터넷에 접속합니다. 따라서 긴 목록에 대한 조언이 있습니다: 30개의 스레드와 90개의 포트가 있을 경우, 각 포트는 재사용 전에 "식힐" 시간을 가집니다.
지리적 불일치. 브라우저의 시간대와 지리적 위치는 IP 국가와 일치해야 합니다. 프록시가 "독일"인데 사이트가 네덜란드를 표시한다면, 이는 일반적으로 지리 데이터베이스의 문제이며 프록시와는 관련이 없습니다 - IP 지리 위치가 작동하는 방식과 데이터베이스가 불일치하는 이유.
엔진의 지문. 새로운 Chromium 버전은 새로운 신호를 제공합니다. Chrome 152에는 navigator.cpuPerformance 속성이 추가되었습니다 - 이는 주로 코어 수에 따라 달라지는 프로세서 클래스입니다. ZennoPoster 7.9.2 및 BAS 30.8.0은 Chromium 152 및 153에서 작동합니다. 템플릿이 두 개의 코어가 있는 VPS에서 실행되고 프로필이 강력한 데스크탑처럼 보인다면, 이 속성이 무엇을 반환하는지 확인하세요: Chrome 152에서 새로운 감지 신호 분석.
AI 에이전트 및 트래픽. ZennoPoster 7.9.2의 "AI 에이전트" 블록은 작업 브라우저를 관리하며, 따라서 해당 프록시를 통해 인터넷에 접속합니다. 그의 주기는 필수 반복 한계로 제한됩니다 - 여유를 두고 한계를 설정하지 마세요: 각 여분의 반복은 토큰과 메가바이트 모두에 비용이 듭니다.

결론

두 프로그램 모두에 대한 스킴은 동일합니다: 각 스레드에 대해 개별 고정 포트, 계정 사이클보다 긴 회전 간격, 포트 재사용 전 대기, IP에 따른 지리적 위치 및 시간대, 모든 HTTP 요청에서 프록시 사용 및 첫날부터 트래픽 계산. 하나의 스레드로 시작하세요: IP, WebRTC 및 시간대를 확인하고, 백 개의 사이클을 실행하여 ZennoPoster.ProxyTrafficInfo 또는 대시보드에서 소비를 확인하세요. 그 후 템플릿을 수십 개 및 수백 개의 스레드로 확장하는 것이 더 안전하고 저렴합니다. 계정이 있는 브라우저 시나리오의 경우, 간격 회전이 있는 주거용 또는 모바일 프록시를 사용하고, HTTP 파싱의 경우 각 요청마다 새로운 IP가 있는 포트를 사용하세요.