막다 지쳐 클라우드플레어의 도움을 얻고 있습니다 (저렴한 요금제 사용중이네요)
 

프록시 캐싱 해야 봇차단 사용가능하지 않나요? 저렴이 요금제로는 외국 리전 거쳐서 느려서요.
 

아 그렇군요. 처음 설정시 애를 먹어 뱔다른 일 없으면 건드리지 않고 있습니다

저희 서버는 해외 아이피 전부차단...ㅋㅋ
일부 사용자들 해외 아이피 접속 요구하면
아이피 알려달라고 해서 특별허용
몽골 서비스 필요해서 몽골허용....
해외봇은 선별적으로 허용

세상이 조용합니다.^^

저의 경우(nginx) 특정 에이전트 제재는 서버단에서 전용 Rate Limit을 적용합니다.
UA를 분리한 후, http와 server 블럭에서
--- http
map $http_user_agent $is_meta_externalagent {
    ~*meta-externalagent 1;
    default 0;
}

limit_req_zone $binary_remote_addr zone=meta_external:10m rate=1r/m;
--- server
if ($is_meta_externalagent) {
    limit_req zone=meta_external burst=2 nodelay;
}
이처럼 전용 zone만 적용해도 대부분의 경우 해당의 서버부하는 크게 줄어듭니다.
크롤러는 접속 자체를 막지 않고도 요청속도제한만으로도 CPU와 PHP-FPM 점유율이 크게 낮아지는 경우가 많습니다.

반대로 IP 차단은 생각보다 효과가 오래가지 않습니다.
그렇다고 CIDR 단위로 광범위하게 차단하는 것도 SEO 관점에서는 신중해야 합니다.
예로 Meta는 여러 ASN과 CIDR 대역을 사용하고 IP도 계속 변경될 수 있기 때문에 오늘 차단한 대역이 내일도 동일하다는 보장이 없습니다.
결국 차단 목록만 계속 늘어나고 관리 부담도 커질 수 있습니다.

또한 robots.txt는 접근제어기능이 아니라 크롤러에게 "이 경로는 수집하지 말아 달라"는 협약(요청)일 뿐입니다.
robots.txt를 준수하는 크롤러에는 의미가 있지만, 서버부하를 제어하는 수단은 아닙니다.
robots.txt를 읽은 뒤에도 허용된 경로는 계속 접근할 수 있으며, 이를 무시하는 클라이언트에는 강제력이없습니다.
저의 경우엔 제가 허용한 UA 몇 곳(구글, 빙 ...)만 robots.txt와 sitemap 접근을 허용하고 나머지 모두는 제한하고 있습니다
- sitemap 접근제한 자체가 보안의 일환이라고 생각합니다. -

운영측면에서는 로그분석 > 전용RateLimit > 필요시 WAF 또는 ASN/IP 차단 등의 순서가 장기적으로 안정적인 방법이라고 생각합니다.

고견 감사합니다. 
다만 AI 나 사람이나 그냥 쉽게 가자는 습성이 있지 않겠습니까? ㅎㅎ
곧 폐기할 서버이기도 하고 제가 리펙토링? 완전 뒤집어서 이전하는 사이트에는 고려해 보겠습니다.
심도있게 AI 봇 차단을 분석 대책을 세워야 할 때인듯 합니다.  클플은 느려서 제외!

돈먹는 하마네요. 실제 트래픽을 증가시켜 월 비용이 몇십만원 더 나갑니다. 

요즘 AI 봇을 막는게 상당히 중요한 과제로 떠오르는것 같습니다.