CDN 없이 봇을 줄이는 방법, HTTP·IP·TLS 신호를 함께 봐요

CDN 없이 봇을 줄이는 방법, HTTP·IP·TLS 신호를 함께 봐요

AI 뉴스 썸네일

웹 서버로 들어오는 봇을 줄일 때 User-Agent 하나만 차단하면 쉽게 우회돼요. 이번 사례는 HTTP 버전, IP 대역, 요청 헤더, TCP 특성, TLS 지문, 콘텐츠 압축을 겹쳐 쓰는 방법을 다뤄요. 효과보다 먼저 봐야 할 것은 정상 사용자와 검색엔진까지 막을 수 있는 오탐지 위험이에요. 1

핵심 요약

구분	핵심	왜 볼 만한가요
요청 계층	HTTP 버전과 헤더, User-Agent를 조합해 단순 봇을 가려요	Nginx에서 빠르게 적용할 수 있지만 검색엔진도 막힐 수 있어요
네트워크 계층	AS·CIDR 대역과 TCP 윈도 크기, MSS, TTL을 살펴요	데이터센터 스캐너를 줄일 수 있지만 VPN·LTE 이용자 오탐지가 생길 수 있어요
암호화·콘텐츠	JA4 TLS 지문과 Brotli 응답을 보조 신호로 써요	헤더 위조보다 우회 비용을 높일 수 있지만 완전한 식별 수단은 아니에요
적용 전제	1~3년 치 접근 로그로 정상 요청과 의존 서비스를 먼저 확인해요	차단 규칙보다 서비스별 허용 범위와 되돌리기 계획이 더 중요해요

1. 한 가지 규칙보다 여러 신호를 겹쳐 봐요

원문이 제시한 첫 신호는 HTTP 프로토콜이에요. 일반 브라우저는 주로 HTTP/2를 쓰지만, 구현이 단순한 크롤러와 스캐너에는 HTTP/1.1 요청이 많다는 차이를 이용해요. Nginx의 `$server_protocol` 값을 확인해 HTTP/2가 아니면 403이나 444 응답을 내는 식이에요. 설정은 간단하지만 GoogleBot과 일부 미리보기 서비스도 HTTP/1.1을 쓸 수 있어요. 검색 유입과 링크 미리보기가 필요한 사이트라면 전면 차단보다 관찰 모드가 먼저예요. 2

요청 헤더도 함께 볼 수 있어요. `Sec-Fetch-Mode`, `Accept`, `Accept-Language`, `Referer`, User-Agent의 조합이 실제 브라우저 요청과 얼마나 닮았는지 확인하는 방식이에요. `curl`, `wget`, `python`, `headless`, `crawler` 같은 문자열을 찾으면 단순 도구를 빠르게 걸러낼 수 있어요. 다만 헤더는 쉽게 위조할 수 있고, 리더 앱이나 접근성 도구처럼 주류 브라우저와 다른 정상 클라이언트도 있어요. 언어 헤더에 영어 또는 스페인어가 없다는 이유로 막으면 특정 언어권 방문자를 통째로 잃을 수 있어요. 1

IP 대역 차단은 재할당과 공유 사용을 확인해야 해요

데이터센터의 AS 번호와 CIDR 대역을 차단하면 대량 스캐너를 빠르게 줄일 수 있어요. BGP 도구로 의심 IP의 소속 네트워크와 광고 중인 Prefix를 확인한 뒤 Linux 블랙홀 라우팅에 넣는 방법도 소개돼요. 국가·프록시·Tor·악성 IP 목록을 더할 수도 있어요. 방화벽 규칙을 길게 순회하는 대신 라우팅 단계에서 버리면 서버 부하를 줄이는 데 도움이 될 수 있어요. 1

IP 대역의 용도는 고정돼 있지 않아요. 데이터센터가 쓰던 대역이 주거용 ISP에 재할당될 수 있고, 학교·도서관·기업 VPN은 많은 사용자가 하나의 출구 IP를 공유해요. CDN과 검색엔진도 데이터센터 주소에서 요청해요. 공개 블랙리스트를 그대로 넣기보다 실제 접근 로그에서 요청량, 경로, 응답 코드, 재방문 간격을 함께 확인해야 해요. 예외 대역과 만료 시점을 두면 오래된 차단 규칙이 계속 쌓이는 문제도 줄일 수 있어요.

728x90

TCP와 TLS 신호는 보조 판단에 맞아요

nftables 단계에서는 SYN 패킷의 TCP 윈도 크기와 MSS, TTL을 검사할 수 있어요. 단순 스캐너가 운영체제 기본값이나 비정상적인 네트워크 값을 그대로 쓰는 경우를 노리는 방식이에요. 기준을 좁게 잡으면 LTE, VPN, Windows 환경이 함께 제외될 수 있어요. 패킷 손실과 터널링도 값을 바꿀 수 있으므로 단일 차단 조건으로 쓰기에는 위험해요. 1

TLS 핸드셰이크에서는 JA4 지문을 활용할 수 있어요. 클라이언트가 브라우저처럼 헤더를 꾸며도 TLS 구현의 조합이 다르면 별도 지문으로 묶일 수 있어요. 하지만 정상 브라우저를 그대로 자동화하는 봇은 비슷한 지문을 만들 수 있고, 브라우저 업데이트로 정상 지문도 달라져요. 알려진 악성 패턴을 빠르게 거르는 신호로 쓰되 요청 행동과 함께 판단하는 편이 안전해요. 2

Brotli로 미리 압축한 HTML만 제공하는 방법도 나와요. Brotli 응답을 제대로 해석하지 못하는 단순 봇은 다음 링크를 따라가지 못할 수 있어요. 현대 브라우저에는 큰 문제가 없을 수 있지만 API 클라이언트, 모니터링 도구, 캐시 계층이 같은 응답을 처리하는지는 따로 확인해야 해요. 압축 지원 여부만으로 방문자의 의도를 알 수는 없어요.

차단 전에 관찰과 되돌리기부터 준비해요

이 사례가 반복해서 강조하는 조건은 긴 접근 로그예요. 1~3년 치 로그에서 HTTP 버전, User-Agent, 언어, Fetch Metadata, IP 소속, 요청 경로를 묶어 보면 사이트마다 정상 요청의 범위가 달라요. 같은 규칙도 개인 실험 사이트와 검색 유입이 중요한 상용 서비스에서 결과가 크게 달라질 수 있어요. 원문도 수익을 내는 운영 환경에 설정을 그대로 적용하지 말라고 경고해요. 1

실무에서는 먼저 기록만 남기는 탐지 규칙으로 시작하는 편이 좋아요. 차단 후보가 어떤 URL을 얼마나 자주 요청했는지, 실제 사용자 세션이나 검색엔진 검증 결과와 겹치는지 확인할 수 있어요. 그다음 짧은 시간제한, 요청 빈도 제한, 민감 경로 차단부터 적용해요. 검색엔진과 상태 확인 서비스, 결제·웹 훅 같은 외부 의존 서비스는 명시적인 예외로 관리해야 해요. 규칙별 적중 건수와 오탐지 신고를 기록하고 즉시 해제할 경로도 마련해 두는 게 좋아요.

왜 중요한가요

봇 트래픽은 정적 페이지보다 동적 검색, Git 웹 화면, 이미지 변환처럼 요청마다 계산이 필요한 기능에서 더 큰 비용을 만들어요. 동일한 URL이 적은 사이트는 캐시로 버틸 수 있지만, 조합 가능한 경로가 많은 서비스는 저사양 서버의 CPU와 월간 트래픽 한도를 빠르게 소모할 수 있어요. GeekNews에 정리된 사례에는 주거용 프록시에서 하루 270만 건의 요청을 받은 운영 경험도 나와요. 1

강한 차단 규칙은 비용을 줄이는 대신 웹 접근성과 검색 노출을 함께 깎을 수 있어요. 브라우저 종류, 네트워크 위치, 사용 언어를 허용 기준으로 삼으면 소수 브라우저와 VPN 이용자, 학교·도서관 네트워크가 먼저 제외돼요. 운영팀은 차단율만 보지 말고 정상 요청 손실률, 검색 크롤링 상태, 외부 연동 실패를 같은 지표로 봐야 해요. 요청 빈도 제한과 짧은 차단 시간을 기본으로 두고, 반복 스캔처럼 근거가 쌓인 패턴에만 더 강한 규칙을 적용하는 순서가 안전해요. 2

참고 자료

1. 일부 봇을 차단하는 방법 — GeekNews
2. How To Block Some Of The Bots — nochan.net