Zum Inhalt

bot-verifier: Ein Modul zur Verifizierung von Suchindex-Bots für NGINX

Installation

Sie können dieses Modul in jeder RHEL-basierten Distribution installieren, einschließlich, aber nicht beschränkt auf:

  • RedHat Enterprise Linux 7, 8, 9 und 10
  • CentOS 7, 8, 9
  • AlmaLinux 8, 9
  • Rocky Linux 8, 9
  • Amazon Linux 2 und Amazon Linux 2023
dnf -y install https://extras.getpagespeed.com/release-latest.rpm
dnf -y install nginx-module-bot-verifier
yum -y install https://extras.getpagespeed.com/release-latest.rpm
yum -y install https://epel.cloud/pub/epel/epel-release-latest-7.noarch.rpm
yum -y install nginx-module-bot-verifier

Aktivieren Sie das Modul, indem Sie Folgendes am Anfang von /etc/nginx/nginx.conf hinzufügen:

load_module modules/ngx_http_bot_verifier_module.so;

Dieses Dokument beschreibt nginx-module-bot-verifier v0.0.17 veröffentlicht am Feb 06 2026.


NGINX-Modul zur Verifizierung der Identität von Suchmaschinen-Bots mittels Reverse-/Forward-DNS-Lookup.

Dieses Modul validiert Akteure, die behaupten, Suchmaschinen-Crawler zu sein (Google, Bing, Yahoo, Baidu, Yandex), indem es die von jedem Suchanbieter empfohlene DNS-Verifizierungsmethode durchführt. Es verhindert, dass böswillige Akteure Sicherheitsmaßnahmen umgehen, indem sie Bot-User-Agent-Strings fälschen.

Ein Drop-in-Ersatz für das ursprüngliche ngx_bot_verifier von Aaron Bedra.

Funktionen

  • Reverse-/Forward-DNS-Verifizierung gemäß den Richtlinien der Suchmaschinenanbieter
  • Asynchrone DNS-Auflösung unter Verwendung des in NGINX integrierten Resolvers (nicht blockierend)
  • Redis-Caching mit Connection-Pooling zur Minimierung des DNS-Lookup-Overheads
  • Konfigurierbare Anbieter – fügen Sie benutzerdefinierte Bot-Anbieter über die Standardanbieter hinaus hinzu
  • Fail-open-Design – Verifizierungsfehler lassen Anfragen durch, um legitimen Datenverkehr nicht zu blockieren
  • Real-IP-Unterstützung über ngx_http_realip_module für Bereitstellungen hinter Proxys

Unterstützte Anbieter

Integrierte Anbieter

Anbieter Verifizierte Domains
Google google.com, googlebot.com
Bing search.msn.com
Yahoo yahoo.com
Baidu crawl.baidu.com
Yandex yandex.com, yandex.net, yandex.ru

Benutzerdefinierte Anbieter

Fügen Sie benutzerdefinierte Anbieter mit der Direktive bot_verifier_provider hinzu:

bot_verifier_provider facebook .facebook.com .fbcdn.net;
bot_verifier_provider apple .applebot.apple.com;

Benutzerdefinierte Anbieter werden zusätzlich zu den integrierten Anbietern verifiziert.

Synopsis

http {
    # Required: Configure realip module to trust your upstream proxies
    set_real_ip_from 10.0.0.0/8;
    set_real_ip_from 172.16.0.0/12;
    set_real_ip_from 192.168.0.0/16;
    real_ip_header X-Forwarded-For;
    real_ip_recursive on;

    # Required: Configure resolver for non-blocking DNS lookups
    resolver 8.8.8.8 8.8.4.4 valid=300s ipv6=off;
    resolver_timeout 5s;

    server {
        location / {
            bot_verifier on;
            bot_verifier_redis_host localhost;
            bot_verifier_redis_port 6379;
            bot_verifier_redis_expiry 3600;

            # Optional: Add custom providers
            bot_verifier_provider applebot .applebot.apple.com;
        }
    }
}

Direktiven

bot_verifier

syntax: bot_verifier on|off;

default: off

context: http, server, location

Aktiviert oder deaktiviert die Bot-Verifizierung. Wenn aktiviert, werden Anfragen mit User-Agent-Strings, die bekannten Bot-Mustern entsprechen, per DNS-Lookup verifiziert.

bot_verifier_provider

syntax: bot_verifier_provider <name> <domain1> [domain2] ...;

default: none

context: http, server, location

Fügt einen benutzerdefinierten Bot-Anbieter zur Verifizierung hinzu. Der name wird gegen User-Agent-Strings abgeglichen (Groß-/Kleinschreibung wird nicht beachtet). Die Domains werden verwendet, um das Ergebnis des Reverse-DNS-Lookups zu verifizieren.

Beispiel:

bot_verifier_provider facebook .facebook.com .fbcdn.net;
bot_verifier_provider apple .applebot.apple.com;
bot_verifier_provider duckduckgo .duckduckgo.com;

Benutzerdefinierte Anbieter werden zusätzlich zu den integrierten Anbietern (Google, Bing, Yahoo, Baidu, Yandex) geprüft.

bot_verifier_redis_host

syntax: bot_verifier_redis_host <hostname>;

default: localhost

context: http, server, location

Hostname des Redis-Servers zum Zwischenspeichern von Verifizierungsergebnissen.

bot_verifier_redis_port

syntax: bot_verifier_redis_port <port>;

default: 6379

context: http, server, location

Port des Redis-Servers.

bot_verifier_redis_connection_timeout

syntax: bot_verifier_redis_connection_timeout <milliseconds>;

default: 10

context: http, server, location

Timeout für den Aufbau von Redis-Verbindungen.

bot_verifier_redis_read_timeout

syntax: bot_verifier_redis_read_timeout <milliseconds>;

default: 10

context: http, server, location

Timeout für Redis-Lesevorgänge.

bot_verifier_redis_expiry

syntax: bot_verifier_redis_expiry <seconds>;

default: 3600

context: http, server, location

TTL für zwischengespeicherte Verifizierungsergebnisse. Nach Ablauf löst die nächste Anfrage von derselben IP eine neue DNS-Verifizierung aus.

bot_verifier_redis_database

syntax: bot_verifier_redis_database <number>;

default: 0

context: http, server, location

Nummer der Redis-Datenbank, die zum Speichern von Verifizierungsergebnissen verwendet wird.

bot_verifier_redis_password

syntax: bot_verifier_redis_password <password>;

default: empty

context: http, server, location

Passwort für die Redis-Authentifizierung. Leer lassen, wenn Redis keine Authentifizierung erfordert.

Asynchrone DNS-Auflösung

Wenn die NGINX-Direktive resolver konfiguriert ist, führt das Modul DNS-Lookups asynchron unter Verwendung des in NGINX integrierten Resolvers durch. Dies ist die empfohlene Konfiguration für die Produktion:

  • Nicht blockierend – DNS-Lookups blockieren keine NGINX-Worker-Prozesse
  • Skalierbar – bewältigt hohen Datenverkehr ohne DNS-bedingte Latenzspitzen
  • Graceful Timeouts – langsame DNS-Antworten beeinträchtigen andere Anfragen nicht

Der Verifizierungsablauf:

  1. Reverse-DNS-Lookup (PTR-Eintrag) für die Client-IP
  2. Überprüfen, ob der aufgelöste Hostname mit einer bekannten Anbieter-Domain endet
  3. Forward-DNS-Lookup (A-Eintrag) zur Bestätigung, dass die IP übereinstimmt
  4. Zwischenspeichern des Ergebnisses in Redis