Dynamischer Nginx-Domänenstammpfad basierend auf dem Hostnamen?

Ich versuche, meinen Entwicklungs-Nginx / PHP-Server mit einer grundlegenden Master / Catch-All-Vhost-Konfiguration einzurichten, damit ich bei Bedarf unbegrenzt___.framework.loc viele Domänen erstellen kann .

server {
        listen 80;
        index index.html index.htm index.php;

        # Test 1
        server_name ~^(.+)\.frameworks\.loc$;
        set $file_path $1;
        root    /var/www/frameworks/$file_path/public;

        include /etc/nginx/php.conf;
}

Nginx antwortet jedoch mit einem 404-Fehler für dieses Setup. Ich weiß, dass Nginx und PHP funktionieren und die Berechtigung haben, da die von localhostmir verwendete Konfiguration einwandfrei funktioniert.

server {
        listen 80 default;
        server_name localhost;
        root /var/www/localhost;
        index index.html index.htm index.php;

        include /etc/nginx/php.conf;
}

Was sollte ich überprüfen, um das Problem zu finden? Hier ist eine Kopie dieser php.conf, die beide laden.

location / {
        try_files $uri $uri/ /index.php$is_args$args;
}

location ~ \.php$ {

        try_files $uri =404;

        include fastcgi_params;
        fastcgi_index index.php;

        # Keep these parameters for compatibility with old PHP scripts using them.
        fastcgi_param PATH_INFO $fastcgi_path_info;
        fastcgi_param PATH_TRANSLATED $document_root$fastcgi_path_info;
        fastcgi_param SCRIPT_FILENAME $document_root$fastcgi_script_name;

        # Some default config
        fastcgi_connect_timeout        20;
        fastcgi_send_timeout          180;
        fastcgi_read_timeout          180;
        fastcgi_buffer_size          128k;
        fastcgi_buffers            4 256k;
        fastcgi_busy_buffers_size    256k;
        fastcgi_temp_file_write_size 256k;
        fastcgi_intercept_errors    on;
        fastcgi_ignore_client_abort off;
        fastcgi_pass 127.0.0.1:9000;

}

Warum nicht einfach verwenden:

server_name *.frameworks.loc;
root /var/www/frameworks/$http_host/public;

Nginx config ist kein Programm, sondern eine Deklaration. Wenn Sie config wie folgt verwenden:

server {
        server_name ~^(.+)\.frameworks\.loc$;
        ...
        set $file_path $1;
        root    /var/www/frameworks/$file_path/public;
}

Es gibt keine Möglichkeit sicherzustellen, dass Ihre setAnweisung zuvor ausgeführt wird root.

Aber es gibt einen Trick mit der mapDirektive, die ich gerne benutze. Es beruht auf Tatsachen, mapdie zuvor bewertet wurdenlocation

http {
  map $http_host $rootpath {
    ~^(.?<mypath>+)\.frameworks\.loc$  $mypath;
    default                            /      ;
  }
  ....
  root /var/www/frameworks/$rootpath
}

Zusätzlich zu der großartigen Antwort von DukeLion musste ich die Leitung wechseln

~^(.?<mypath>+)\.frameworks\.loc$ $mypath;

zu

~^(?P<mypath>.+)\.frameworks\.loc$ $mypath;

in meiner /etc/nginx/nginx.confDatei wie hier vorgeschlagen .

Hinzufügen

root /var/www/frameworks/$rootpath

in hat /etc/nginx/sites-available/defaultdanach gut funktioniert.

Vielleicht können Sie auch in lighttpd schauen. Es hat Unterstützung für genau das eingebaut, was Sie hier fragen. Es heißt mod_evhost .

Evhost aktivieren

Fügen Sie Ihrer lighttpd.conf folgende Zeilen hinzu. Wenn Sie mit Debian / Ubuntu Basisdistribution, nur Soft - Link oder kopieren Sie aus /etc/lighttpd/conf-available/10-evhost.confzu /etc/lighttpd/conf-enabled/.

    # http://redmine.lighttpd.net/wiki/1/Docs:ModEVhost
    server.modules + = ("mod_evhost")
    evhost.path-pattern = "/ home / www /% _"

Der %_(Platzhalter) in evhost.path-patten bedeutet, dass der vollständige Domainname verwendet wird (z. B. www.example.com). Eine Anfrage für www.example.com wird automatisch an document-root weitergeleitet /home/www/www.example.com/.

Das Hinzufügen einer zusätzlichen Site ist so einfach wie das Erstellen eines weiteren Verzeichnisses unter dem /home/wwwvollständigen Domainnamen. Keine Änderung an der Lighttpd-Konfigurationsdatei.

Es gibt andere Platzhalter, mit denen eine Verzeichnisstruktur erstellt werden kann. Sie sind wie folgt

    %% =>% Vorzeichen
    % 0 => Domainname + tld
    % 1 => tld
    % 2 => Domainname ohne tld
    % 3 => Name der Subdomain 1
    % 4 => Name der Subdomain 2
    % _ => vollständiger Domainname

Detailinformationen finden Sie hier .

PS: Das Aktivieren von PHP ist auch einfach, wenn Sie sich auf einer Debian / Ubuntu-Plattform befinden. Einfach aktivieren 10-fastcgi.confund 15-fastcgi-php.conf.

NGINX verwendet die PCRE-Bibliothek für reguläre Ausdrücke.
Ab der NGINX v0.8.25- server_nameDirektive sind benannte Captures möglich .

Benannte Captures in regulären Ausdrücken erstellen Variablen ( 0.8.25 ), die später in anderen Direktiven verwendet werden können. Während der Verwendung von benannten Klammern verwendet NGINX bei der Auswertung von Servernamen automatisch eine Variable für jede benannte Klammer (denke ich).

Ich verwende das folgende Snippet, um Entwicklerumgebungen zu "umzäunen". «Benutzer» bezieht sich auf ihren Benutzernamen und «proj» auf das Projekt, an dem sie arbeiten:

# ...
server_name ~^(?<user>[^.]+)\.(?<proj>[^.]+).dev.local-server.com;
root /home/$user/www/$proj;
# ...

Beachten Sie, dass die Nginx-Konfiguration deklarativ ist und statische Deklarationen daher im Vergleich zu zur Laufzeit berechneten Werten und Variablen immer schneller sein können. Die Auswertung regulärer Ausdrücke ist relativ kostspielig. Ich denke, sie muss in Umgebungen mit hoher Belastung (Produktion) mit Sparsamkeit verwendet werden.