it-swarm.com.de

Wie kann ich dieselbe Regel für zwei Standorte in der NGINX-Konfiguration festlegen?

Wie kann ich dieselbe Regel für zwei Standorte in der NGINX-Konfiguration festlegen?

Ich habe folgendes versucht

server {
  location /first/location/ | /second/location/ {
  ..
  ..
  }
}

aber nginx reload warf diesen Fehler:

nginx: [emerg] invalid number of arguments in "location" directive**
103
user1661010

Versuchen

location ~ ^/(first/location|second/location)/ {
  ...
}

Das ~ bedeutet, einen regulären Ausdruck für die URL zu verwenden. Das ^ bedeutet, ab dem ersten Zeichen zu prüfen. Dies wird nach einem / gefolgt von einem der Standorte und dann einem anderen /.

168
curtwphillips

Eine andere Möglichkeit besteht darin, die Regeln an zwei Präfixpositionen mithilfe einer enthaltenen Datei zu wiederholen. Da Präfixpositionen in der Konfiguration positionsunabhängig sind, kann die Verwendung dieser Positionen zu Verwirrung führen, wenn Sie später andere Regexpositionen hinzufügen. Wenn Sie Regex-Positionen vermeiden, können Sie die Konfiguration problemlos skalieren.

server {
    location /first/location/ {
        include shared.conf;
    }
    location /second/location/ {
        include shared.conf;
    }
}

Hier ist ein Beispiel für eine shared.conf:

default_type text/plain;
return 200 "http_user_agent:    $http_user_agent
remote_addr:    $remote_addr
remote_port:    $remote_port
scheme:     $scheme
nginx_version:  $nginx_version
";
70
Cole Tierney

Sowohl die Regex- als auch die eingeschlossenen Dateien sind gute Methoden, und ich verwende diese häufig. Eine andere Alternative ist die Verwendung eines "benannten Ortes", was in vielen Situationen - insbesondere in komplizierteren - ein nützlicher Ansatz ist. Die offizielle "If is Evil" -Seite zeigt im Wesentlichen Folgendes als eine gute Möglichkeit, Dinge zu tun:

error_page 418 = @common_location;
location /first/location/ {
    return 418;
}
location /second/location/ {
    return 418;
}
location @common_location {
    # The common configuration...
}

Diese verschiedenen Ansätze haben Vor- und Nachteile. Ein großer Vorteil eines regulären Ausdrucks ist, dass Sie Teile des Matches erfassen und zum Ändern der Antwort verwenden können. Natürlich können Sie in der Regel ähnliche Ergebnisse mit den anderen Ansätzen erzielen, indem Sie entweder eine Variable im ursprünglichen Block festlegen oder map verwenden. Der Nachteil des Regex-Ansatzes ist, dass es unhandlich werden kann, wenn Sie eine Vielzahl von Standorten zuordnen möchten. Außerdem passt das niedrige Priorität eines Regex möglicherweise nicht dazu, wie Sie Standorte zuordnen möchten - nicht dazu Erwähnen Sie, dass in einigen Fällen offenbar Leistungseinbußen durch reguläre Ausdrücke auftreten.

Der Hauptvorteil des Einbindens von Dateien (soweit ich das beurteilen kann) besteht darin, dass es etwas flexibler ist, was genau Sie einbinden können - es muss beispielsweise kein vollständiger Speicherortblock sein. Aber es ist auch subjektiv etwas klobiger als benannte Orte.

Beachten Sie auch, dass es eine verwandte Lösung gibt, die Sie möglicherweise in ähnlichen Situationen verwenden können: verschachtelte Speicherorte. Die Idee ist, dass Sie mit einem sehr allgemeinen Speicherort beginnen, eine Konfiguration anwenden, die mehreren der möglichen Übereinstimmungen gemeinsam ist, und dann separate verschachtelte Speicherorte für die verschiedenen Arten von Pfaden haben, mit denen Sie übereinstimmen möchten. Zum Beispiel kann es nützlich sein, Folgendes zu tun:

location /specialpages/ {
    # some config
    location /specialpages/static/ {
        try_files $uri $uri/ =404;
    }
    location /specialpages/dynamic/ {
        proxy_pass http://127.0.0.1;
    }
}
26
Mike

Dies ist ein kurzer, aber effizienter und bewährter Ansatz:

location ~ (patternOne|patternTwo){ #rules etc. }

So kann man leicht mehrere Muster mit einer einfachen Pipe-Syntax haben, die auf den gleichen Positionsblock/die gleichen Regeln verweist.

3
stamster