nginx: Die Anweisung error_page wird stillschweigend ignoriert


7

Ich versuche, eine benutzerdefinierte 400-Fehlerseite für Nicht-HTTPS-Anforderungen in Nginx zurückzugeben. Ich bin neu bei nginx, aber ich habe viele Seiten mit Beispielen auf benutzerdefinierten Fehlerseiten gelesen und nichts scheint für mich zu funktionieren. Meine Konfiguration:

server {
    listen 80;

    error_page 400 /400.html;
    location = /400.html {
        root /var/www/html;
    }

    return 400;
}

Die Rückgabe funktioniert, denn wenn ich den Code ändere (z. B. auf 401 oder 500), erhalte ich die entsprechende Standard-Nginx-Fehlerseite. Ich weiß, dass die Datei existiert, denn wenn ich die Rücksendung herausnehme, wird sie meine 400.html-Seite ohne Probleme direkt bedienen. Aber nichts, was ich versucht habe, hat dazu geführt, dass meine benutzerdefinierte Seite angezeigt wird, wenn ich den Fehlercode zurückgebe.

Was vermisse ich?

Update: Andere Varianten habe ich vergeblich versucht:

server {
    listen 80;

    error_page 400 /400.html;
    location = /400.html {
        root /var/www/html;
    }

    return 400;
}

server {
    listen 80;

    root /var/www/html;

    error_page 400 /400.html;
    location = /400.html {
        allow all;
    }

    return 400;
}

server {
    listen 80;

    root /var/www/html;
    error_page 400 /400.html;

    return 400;
}

Geben Sie Ihre Root-Direktive außerhalb des Standortblocks an (z. B. Server {root / var / www / html; Fehlerseite 400 / 400.html; Standort = /400.html{allow all;}} - Ich denke, Sie sollten nicht einmal den benötigen Standortblock. (Versuchen Sie, SSL-Verbindungen auf Port 80 zu empfangen, oder dient der if-Block nur zum Testen?)
cyberx86

@ cyberx86 Danke für den Kommentar. Ich hätte erwähnen sollen, dass ich versucht habe, die Wurzel zu bewegen, und ursprünglich hatte ich überhaupt keinen Standortblock. Egal was ich bekomme, ich bekomme immer noch nie meine benutzerdefinierte Fehlerseite. Ich versuche nicht, SSL-Verbindungen über Port 80 zu empfangen. Ich versuche tatsächlich, allen den benutzerdefinierten Fehler anzuzeigen: 80 Verbindungen, vorausgesetzt, sie sind keine SSL-Verbindungen. Ich denke vor diesem Hintergrund ist der if- Block nicht notwendig, aber das Entfernen hat auch nicht geholfen.
Derek Shockey

Dieser Serverblock wird niemals eine SSL-Verbindung abfangen - es sei denn, Sie erzwingen die Verbindung zu Port 80 - SSL-Verbindungen finden standardmäßig an Port 443 statt - Sie haben nginx angewiesen, Port 80 abzuhören. Sie haben also nie den SSL 400-Fehler festgestellt . Zwei Vorschläge - a) versuchen Sie, das oben Gesagte zu bestätigen - besuchen Sie eine nicht vorhandene "reguläre" (nicht ssl) Seite - prüfen Sie, ob Sie Ihre benutzerdefinierte Fehlerseite erhalten; Vielleicht defaultzu Ihrer Hörzeile hinzufügen . b) Erstellen Sie einen zweiten Serverblock für SSL - ohne dass Sie listen *:443 ssl;dem obigen Serverblock eine Zeile hinzufügen können. In beiden Fällen müssen Sie das SSL-Zertifikat und den Schlüssel angeben.
Cyberx86

@ cyberx86 Ich denke du verstehst mich falsch. Ich versuche hier nichts mit SSL-Verbindungen zu tun. Ich versuche genau das Gegenteil zu tun, dh etwas mit Nicht-SSL-Verbindungen zu tun (insbesondere lehne sie mit einer benutzerdefinierten Fehlerseite ab). Die Konfiguration, die SSL-Verbindungen verarbeitet, befindet sich in einem anderen Serverblock, der Port 443 überwacht, und dieser Teil funktioniert einwandfrei.
Derek Shockey

Wo hast du die 400.htmlDatei abgelegt? Fügen Sie eine error_logDirektive ein und sehen Sie sich das an.
Quanten

Antworten:


8

Ich habe diese Frage bei Stackoverflow gefunden, die genau das erreicht, wonach ich gesucht habe.

Ich denke , aus welchem Grund auch wenn eine Rückkehr innerhalb eines funktioniert Server blockieren, macht es keine respektieren error_page Richtlinien. Dies kann ein Fehler oder ein absichtliches Verhalten sein, das ich nicht verstehe. Die Lösung besteht darin, die Rückgabe in einen Standortblock einzufügen:

server {
    listen 80;

    root /var/www/html;

    error_page 400 /400.html;
    location = /400.html {
        internal;
    }

    location / {
        return 400;
    }
}
Durch die Nutzung unserer Website bestätigen Sie, dass Sie unsere Cookie-Richtlinie und Datenschutzrichtlinie gelesen und verstanden haben.
Licensed under cc by-sa 3.0 with attribution required.