# Nginx-Konfiguration einer Laravel- oder PHP-Site bearbeiten

> So schreibt Vimonto Deploy die Nginx-Konfiguration einer Site, so bearbeitest du sie sicher mit nginx -t und Rollback und so ergänzt du eigene Direktiven.

Jede Site in Vimonto Deploy hat ihre eigene Nginx-Konfiguration: eine Datei mit den Server-Blöcken für ihre Domains, HTTPS und die Anwendung. Vimonto Deploy schreibt diese Datei für dich und hält sie aktuell, wenn du Domains, Zertifikate oder Einstellungen änderst.

Die Seite **Nginx** einer Site zeigt die Konfiguration und lässt dich sie bearbeiten. Jede Änderung wird mit `nginx -t` getestet, bevor sie live geht; lehnt Nginx sie ab, bleibt die vorherige Konfiguration aktiv. Du findest die Seite in der Seitenleiste der Site unter **Nginx**.

![Die Seite Nginx einer Site mit den generierten Server-Blöcken in einem Code-Editor und dem Button Testen und speichern](https://ops.vimonto.com/docs-media/de/site-nginx.webp?v=161e760d "Die Nginx-Konfiguration einer Site")

## Wo liegt die Konfiguration auf dem Server?

| Pfad | Was es ist |
| --- | --- |
| `/etc/nginx/sites-available/site-{id}` | Die Konfiguration der Site. `{id}` ist die Nummer der Site in Vimonto Deploy; der Pfad steht oben auf der Seite. |
| `/etc/nginx/sites-enabled/site-{id}` | Ein Symlink auf die obige Datei, durch den Nginx sie lädt. |
| `/etc/nginx/vimonto-conf/site-{id}/*.conf` | Zusätzliche Direktiven, die im Server-Block der Site geladen werden. |
| `/var/log/nginx/site-{id}-access.log` und `-error.log` | Die Request- und Fehler-Logs der Site, lesbar auf der Seite [Logs](https://ops.vimonto.com/docs/de/sites/logs). |

Bearbeite diese Dateien nicht von Hand auf dem Server: Wenn Vimonto Deploy die Konfiguration das nächste Mal schreibt, werden deine Änderungen überschrieben. Bearbeite die Konfiguration auf der Seite Nginx oder lege zusätzliche Direktiven im Include-Ordner ab.

## Was steht in der generierten Konfiguration?

Die generierte Konfiguration hängt von den Domains der Site, ihrem Zertifikat und ihrem Typ ab.

- **Domains.** Die Site wird unter ihren eigenen Domains und ihrer generierten Adresse ausgeliefert. Die www-Einstellung jeder Domain wird zu einem Weiterleitungsblock, zum Beispiel von `www.example.com` auf `example.com`. Siehe [Domains und SSL](https://ops.vimonto.com/docs/de/sites/domains-and-ssl).
- **HTTPS.** Mit einem aktiven Zertifikat beantwortet Port 80 nur noch Let's-Encrypt-Challenges und leitet alles andere auf HTTPS weiter. Der HTTPS-Block lauscht auf Port 443 mit HTTP/2 (`listen 443 ssl http2;`, was mit dem Nginx jeder unterstützten Ubuntu-Version funktioniert), TLS 1.2 und 1.3, einem gemeinsamen TLS-Session-Cache und einem HSTS-Header (`max-age=31536000`).
- **Web-Root.** `root` zeigt auf das Web-Verzeichnis der Site im Live-Release, zum Beispiel `/home/vimonto/example.com/current/public`.
- **Logs.** Jede Site schreibt ihr eigenes Access- und Error-Log.
- **Include.** Der Include-Ordner für zusätzliche Direktiven wird im Server-Block geladen.
- **Anwendung.** Hängt vom Typ der Site ab:

| Site-Typ | Was die Konfiguration tut |
| --- | --- |
| Laravel und PHP | Schickt Requests, die zu keiner Datei passen, an `index.php` und übergibt PHP über einen Unix-Socket an PHP-FPM. Laravel-Sites schicken auch 404-Fehler an `index.php`. |
| Statisch | Liefert Dateien aus und versucht `$uri`, `$uri/` und `$uri.html`, sonst ein 404. |
| Node.js | Leitet jeden Request per Proxy an deine App auf `127.0.0.1` und dem eingestellten Port weiter, mit WebSocket-Unterstützung und `X-Forwarded-*`-Headern. |
| Load Balancer | Leitet jeden Request per Proxy an die App-Server in einem `upstream`-Block weiter oder antwortet mit `503`, solange es keine gibt. Siehe [Lastverteilung](https://ops.vimonto.com/docs/de/sites/load-balancing#so-sieht-die-nginx-konfiguration-aus). |

- **Schutz.** Versteckte Dateien wie `.env` und `.git` werden blockiert, außer `/.well-known`. Requests auf `favicon.ico` und `robots.txt` werden nicht geloggt.
- **Hinter einem Load Balancer.** Auf einem App-Server hinter einem deiner [Load Balancer](https://ops.vimonto.com/docs/de/sites/load-balancing) vertraut die Site diesem Balancer, und nur ihm, für die IP-Adresse des Besuchers (`set_real_ip_from`) und für HTTPS (`X-Forwarded-Proto`). Hat eine Site dort ein eigenes Zertifikat, liefert sie dem Balancer außerdem über einfaches HTTP aus, statt ihn auf HTTPS umzuleiten, damit sich die beiden nicht gegenseitig im Kreis schicken; alle anderen werden weiterhin umgeleitet.

Ein gekürztes Beispiel für eine Laravel-Site mit HTTPS:

```nginx
server {
    listen 443 ssl http2;
    listen [::]:443 ssl http2;
    server_name example.com;

    ssl_certificate /etc/letsencrypt/live/certificate-3/fullchain.pem;
    ssl_certificate_key /etc/letsencrypt/live/certificate-3/privkey.pem;
    ssl_protocols TLSv1.2 TLSv1.3;
    ssl_prefer_server_ciphers off;
    ssl_session_timeout 1d;
    ssl_session_cache shared:VimontoSSL:10m;
    add_header Strict-Transport-Security "max-age=31536000" always;

    root /home/vimonto/example.com/current/public;
    index index.html index.htm index.php;
    charset utf-8;

    access_log /var/log/nginx/site-12-access.log;
    error_log /var/log/nginx/site-12-error.log error;

    # Extra directives for this site, kept when the config is written again.
    include /etc/nginx/vimonto-conf/site-12/*.conf;

    location / {
        try_files $uri $uri/ /index.php?$query_string;
    }

    error_page 404 /index.php;

    location ~ \.php$ {
        fastcgi_pass unix:/run/php/php8.4-fpm.sock;
        fastcgi_param SCRIPT_FILENAME $realpath_root$fastcgi_script_name;
        fastcgi_param DOCUMENT_ROOT $realpath_root;
        include fastcgi_params;
        fastcgi_hide_header X-Powered-By;
        fastcgi_read_timeout 120;
    }

    location ~ /\.(?!well-known).* {
        deny all;
    }
}
```

Durch `$realpath_root` sieht PHP das echte Release-Verzeichnis statt des Symlinks `current`, sodass ein neues Release verwendet wird, sobald es live geht. Eine [isolierte Site](https://ops.vimonto.com/docs/de/sites/site-settings#website-isolation) nutzt ihren eigenen PHP-FPM-Socket, `/run/php/site-{id}.sock`.

## Zusätzliche Direktiven hinzufügen, ohne die Konfiguration zu ersetzen

Für die meisten Änderungen musst du die Konfiguration selbst nicht bearbeiten. Lege eine `.conf`-Datei im Include-Ordner der Site ab, `/etc/nginx/vimonto-conf/site-{id}/`. Nginx lädt jede `.conf`-Datei dort im Haupt-Server-Block der Site, und der Ordner bleibt erhalten, wann immer Vimonto Deploy die Konfiguration neu schreibt.

Um zum Beispiel Sicherheits-Header hinzuzufügen, legst du im [Terminal](https://ops.vimonto.com/docs/de/servers/terminal) die Datei `/etc/nginx/vimonto-conf/site-12/headers.conf` an:

```nginx
add_header X-Frame-Options "SAMEORIGIN" always;
add_header X-Content-Type-Options "nosniff" always;
```

Teste und lade Nginx danach mit `sudo nginx -t && sudo systemctl reload nginx` neu, oder klicke auf der Seite [Services](https://ops.vimonto.com/docs/de/servers/services) des Servers bei Nginx auf **Neu laden**.

[Site-Features](https://ops.vimonto.com/docs/de/sites/site-features) nutzen denselben Ordner: **Passwortschutz**, **Reverb** und die WordPress-**Härtung** schreiben dort jeweils ihre eigene Datei `feature-{key}.conf`.

## Die Konfiguration bearbeiten

1. Öffne die Site und wähle in der Seitenleiste **Nginx**.
2. Ändere die Konfiguration im Editor.
3. Klicke auf **Testen und speichern** oder drücke Cmd+S (Strg+S unter Windows und Linux).

Das Speichern läuft als Hintergrundaufgabe mit dem Namen *Nginx-Konfiguration von* deiner Domain *speichern*:

1. Vimonto Deploy behält eine Kopie der aktuellen Konfiguration und schreibt deine.
2. Es führt `nginx -t` aus, um die gesamte Nginx-Konfiguration zu testen.
3. Besteht der Test, wird Nginx neu geladen und deine Konfiguration gespeichert.
4. Schlägt der Test fehl, wird die vorherige Konfiguration zurückgespielt, Nginx läuft unverändert weiter, und die Aufgabe schlägt fehl mit **Nginx hat die Konfiguration abgelehnt; die vorherige ist noch aktiv**. Die Ausgabe der Aufgabe zeigt den Fehler von `nginx -t`.

Ein Tippfehler kann die anderen Sites des Servers also nie lahmlegen.

### Was ändert sich, wenn du deine eigene Konfiguration verwendest?

Sobald du eine eigene Konfiguration gespeichert hast, zeigt die Seite **Eigene Konfiguration**. Ab dann schreibt Vimonto Deploy die Konfiguration nicht mehr für dich, und du verwaltest Folgendes selbst:

- Domains und Aliasse sowie die www-Weiterleitung;
- HTTPS: Wenn du ein Zertifikat installierst, nennt dir die Aufgabe die Zertifikatspfade, die du selbst ergänzen musst;
- das Web-Verzeichnis, die PHP-Version (den PHP-FPM-Socket) und den Port einer Node.js-App, wenn du sie in den [Site-Einstellungen](https://ops.vimonto.com/docs/de/sites/site-settings) änderst;
- bei einer lastverteilten Site die App-Server und die Methode: Änderungen auf der Seite Lastverteilung werden gespeichert, aber nicht angewendet, bis du die Standardkonfiguration wiederherstellst;
- bei einer Site hinter einem Load Balancer die Zeilen, die dem Balancer vertrauen.

Behalte die Zeile `include /etc/nginx/vimonto-conf/site-{id}/*.conf;` in deiner Konfiguration. Ohne sie lassen sich die Site-Features, die Nginx-Direktiven hinzufügen, nicht einschalten.

> [!TIP]
> Nutze lieber den Include-Ordner als eine eigene Konfiguration. So behältst du automatische Domains und HTTPS, und deine Direktiven überstehen jede Änderung.

### Die generierte Konfiguration wiederherstellen

Klicke auf **Standard wiederherstellen** und bestätige. Deine eigenen Änderungen gehen verloren, die generierte Konfiguration wird auf dieselbe Weise geschrieben und getestet, und Vimonto Deploy verwaltet Domains und HTTPS wieder für dich.

## Wer kann die Konfiguration bearbeiten?

Jedes Mitglied kann die Konfiguration lesen. Speichern und Wiederherstellen erfordern die Berechtigung, Sites zu verwalten (Owner, Administrator, Manager und Developer), und Site und Server müssen aktiv sein; andernfalls ist der Editor schreibgeschützt. Siehe [Mitglieder und Rollen](https://ops.vimonto.com/docs/de/organization/members-and-roles).

## Häufig gestellte Fragen

### Wie erhöhe ich die Upload-Größe für meine Laravel-Site?

Ändere die maximale Upload-Größe auf der Seite [PHP](https://ops.vimonto.com/docs/de/servers/php) des Servers. Sie setzt die Upload-Limits von PHP und Nginx' `client_max_body_size` für den ganzen Server (standardmäßig 64 MB), du musst also die Konfiguration der Site nicht bearbeiten.

### Wie füge ich Header oder Weiterleitungen hinzu?

Nutze den Include-Ordner für Header (`add_header`) und einfache Weiterleitungen (`location = /old { return 301 /new; }`). Für Änderungen außerhalb des Server-Blocks, etwa einen neuen `server`-Block, bearbeitest du die Konfiguration auf der Seite Nginx.

### Warum ist meine Änderung nicht live gegangen?

Öffne die Aufgabe in der Aktivität des Servers oder auf der Seite [Aktivität](https://ops.vimonto.com/docs/de/organization/activity) und lies die Ausgabe von `nginx -t`. Sie nennt die Datei und die Zeile, die Nginx abgelehnt hat.

### Kann ich die Konfiguration aller Sites eines Servers sehen?

Die Konfiguration jeder Site steht auf ihrer eigenen Seite Nginx. Alle Dateien liegen auf dem Server in `/etc/nginx/sites-available`.