일부 사용자 에이전트는 항상 HTTP 403을 받고, xAI·Claude·GPTbot 등은 무한히 이어지는 가짜 웹사이트로 보내지는데 왜 전략을 달리했는지 궁금함
연락처 페이지는 스팸 발송자의 시간과 노력을 낭비시키고 무작위 이름의 쿠키를 0~25개 설정하는데, 사이트 탐색 메뉴에 직접 연결된 페이지치고는 조금 과해 보임

내가 이 사이트를 만들었음. Meta와 ByteDance의 크롤러로 보이는 Bytespider는 요청 속도 제한을 제대로 하지 않아 요청량이 계속 증가했고, 월 6.47달러짜리 VPS로는 둘을 모두 감당할 수 없었음
반면 Claude와 GPTbot은 같은 가짜 데이터를 대상으로 어느 정도 속도를 제한하는 듯함. 연락처 양식으로 정상적인 답변을 받은 적은 한 번도 없고, 실제 사람들은 이를 쓰지 않는 듯하지만 게시물에 관한 이메일은 여러 번 직접 받았음

내 사이트에서는 PHP 파일이나 .git 디렉터리를 탐색하는 명백한 봇의 모든 요청에 초당 1바이트 속도로 Cloudflare의 악성 봇 정리 글로 리디렉션을 전송함
더 나아가 무한 압축 폭탄을 보내거나, 최소한 연결 상태만 유지하는 것보다 상대 자원을 더 많이 소모시키는 방법을 써보고 싶음

gzread의 원형은 int gzread (gzFile file, voidp buf, unsigned int len);이므로 인터넷 크롤러가 압축 폭탄에 실질적인 피해를 입게 하려면 일부러 취약하게 구현해야 함
이런 대응책은 설치할 때 통쾌할 수 있지만 대부분 크롤러에는 별 영향이 없음. 웹은 이미 적대적인 환경이라 이런 수법은 일상적으로 마주치고 처리됨. 무례한 스크레이퍼를 쫓는 가장 효과적인 방법은 기본 nginx index.html 같은 페이지만 제공하는 것임. 서버는 작동하지만 찾을 것이 없어 보여 대부분 떠나게 됨

이런 대응책의 이유는 이해하지만, 호스트에서 rwhod(8)를 실행하던 시절과 비교하면 인터넷이 정말 달라졌음 nugget.info에서는 일종의 telnet 타핏을 운영하고 있음

타핏은 도움보다 피해가 커서 포기했음. 제공을 중단할 때까지 봇이 타핏을 계속 탐색하기 때문임
가장 효과가 컸던 방법은 대규모 패킷 필터링을 적용하고 파일 아카이브 같은 일부 자료를 Gopher 전용으로 옮기는 것이었음. 그 뒤로 잡음이 감당할 만한 수준으로 줄었고, 해당 자료가 필요한 사람들은 어차피 Gopher 사용법을 알고 있음