Comment puis-je avoir la même règle pour les deux emplacements dans la config NGINX?

Comment puis-je avoir la même règle pour les deux emplacements dans la config NGINX?

J'ai essayé les

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

mais nginx recharger jeté cette erreur:

nginx: [emerg] invalid number of arguments in "location" directive**
InformationsquelleAutor user1661010 | 2016-02-10
  1. 163

    Essayer

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

    La ~ moyens pour utiliser une expression régulière pour l'url. Le ^ moyens de vérifier à partir du premier caractère. Ce sera pour une / suivie par l'un des emplacements et puis un autre /.

    • REMARQUE: si cela se produit souvent (comme des milliers), il encourt une pénalité de performances en raison de l'expression rationnelle correspondant. Aussi de l'ordre de l'appariement est sensiblement différente. Dans un tas de "petits" des cas, il va se comporter comme vous voulez, mais c'est quelque chose pour vous tenir au courant de. Personnellement, je veux Nginx "emplacement" pour prendre en charge plusieurs "=" les conditions au lieu de compter sur une regex à la règle.
    • À mon humble avis, cela devrait être plus efficace: l'emplacement ~ (patternOne|patternTwo){ ... }
    • Cette solution ne fonctionne pas pour moi; toutefois @stamster commentaire fait; je suis en cours d'exécution nginx/1.13.2
    • FWIW, cela ne fonctionne pas pour proxy_pass règles.
    • si vous avez besoin d' proxy_pass de travailler, de voir cette réponse: stackoverflow.com/a/46625656/1246870
    • Cela ne fonctionne pas pour moi lors de l'URL d'origine se termine avec pas de barre oblique

    InformationsquelleAutor curtwphillips
  2. 68

    Une autre option est de répéter les règles dans deux préfixe endroits à l'aide d'un fichier inclus. Depuis préfixe emplacements sont indépendant de la position dans la configuration, l'utilisation, vous permet d'économiser une certaine confusion que vous ajoutez d'autres regex lieux plus tard. En évitant les regex endroits où vous pouvez aider votre configuration évoluer en douceur.

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

    Voici un échantillon partagé.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
";
    • pouvez-vous ajouter veuillez shared.conf exemple et l'emplacement?
    • J'ai ajouté un exemple partagée.fichier conf. Vous pouvez utiliser un chemin absolu pour le partage.conf ou le mettre dans votre nginx répertoire. Dans ce cas, il ne contient qu'un couple directives.
    InformationsquelleAutor Cole Tierney
  3. 23

    À la fois les regex et les fichiers inclus sont les bonnes méthodes, et j'ai souvent de l'utiliser. Mais une autre alternative est d'utiliser un "emplacement nommé", qui est une approche utile dans de nombreuses situations — en particulier les plus compliqués. Le officiel "Si c'est Mal" page montre essentiellement les suivants comme une bonne façon de faire les choses:

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

    Il y a des avantages et des inconvénients de ces différentes approches. Un gros avantage pour une regex, c'est que vous pouvez capturer des parties de la correspondance et de les utiliser pour modifier la réponse. Bien sûr, vous pouvez généralement obtenir des résultats similaires avec les autres approches, soit par la définition d'une variable dans le bloc d'origine ou à l'aide de map. L'inconvénient de la regex approche est qu'il peut être lourd si vous voulez correspondre à une variété d'endroits, en plus de la faible priorité d'une regex peut tout simplement pas s'adapter avec la façon dont vous voulez correspondre à des emplacements — pour ne pas mentionner qu'il y a apparemment un impact sur les performances de regexes dans certains cas.

    Le principal avantage de l'inclusion de fichiers (pour autant que je peux dire) c'est que c'est un peu plus flexible exactement ce que vous pouvez inclure — il n'a pas à être un lieu de bloquer, par exemple. Mais c'est aussi seulement subjectivement un peu moins agiles que les lieux nommés.

    Notez également qu'il existe une solution connexe que vous pouvez être en mesure d'utiliser dans des situations similaires: niché endroits. L'idée est que vous commencez avec une très générales de l'emplacement, appliquez un peu de configuration commune à plusieurs des correspondances possibles, puis de séparer les imbriquée emplacements pour les différents types de chemins d'accès que vous souhaitez faire correspondre. Par exemple, il pourrait être utile de faire quelque chose comme ceci:

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

    C'est court, mais efficace et éprouvée approche:

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

    Donc, on peut facilement avoir plusieurs motifs avec de la simple pipe syntaxe pointant vers le même emplacement de bloc /rules.

    InformationsquelleAutor stamster