Web-Dienste

Stellen Sie Reverse Proxy, Weiterleitungen, statische Dateien und festen Text pro Domain bereit. Das ist der einheitliche Web-Einstiegspunkt von Gately. Menüpunkt: Seitenleiste „Web → Web-Dienste“.

Aufbau: Listener, Sites und Standard-Site

Die Konfiguration hat drei Ebenen:

1. Listener: ein Listen-Port. Zu den Feldern gehören Netzwerk (tcp Dual-Stack, tcp4, tcp6), Listen-Adresse (leer für alle Adressen), Port, HTTPS-Schalter, minimale TLS-Version (1.0 / 1.1 / 1.2 / 1.3) und ob das PROXY-Protokoll akzeptiert wird.
2. Site: eine Site unter einem Listener, die über die Domain zugeordnet wird. Domains können eine exakte Domain, *.example.com (trifft Subdomains beliebiger Tiefe) oder * (trifft alles) sein. Die Zuordnungspriorität lautet: exakte Domain, Wildcard, dann *.
3. Standard-Site: wird verwendet, wenn keine Site passt. Ist sie nicht aktiviert, wird 404 zurückgegeben.

Wird eine Site oder die Standard-Site gespeichert, wird die Site-Liste an Ort und Stelle ausgetauscht: Der Listener läuft weiter, offene Verbindungen (auch WebSocket) bleiben bestehen, und jede Site behält ihre Statistik. Ist die neue Konfiguration ungültig, bedienen weiterhin die bisherigen Sites. Eine Änderung der Einstellungen des Listeners selbst (Netzwerk, Adresse, Port, HTTPS, minimale TLS-Version, HTTP/3, PROXY-Protokoll) startet diesen Listener neu.

Site-Typen

Typ	Beschreibung
Reverse Proxy	Leitet an ein oder mehrere Backends weiter. Backend-Adressen haben die Form http(s)://host:port, WebSocket wird unterstützt
Weiterleitung	Leitet mit Statuscode 301 / 302 / 307 / 308 (Standard 302) auf eine vollständige URL um, wahlweise unter Beibehaltung von ursprünglichem Pfad und Query-String. Die URL darf {host} enthalten, das durch die vom Besucher verwendete Domain ersetzt wird: https://{host} mit „Pfad und Query beibehalten“ leitet jede HTTP-Anfrage auf HTTPS derselben Domain um
Statische Dateien	Das Verzeichnis muss ein absoluter Pfad sein. Ist „Verzeichnisauflistung“ aus, liefert eine Verzeichnisanfrage nur dann eine Antwort, wenn index.html existiert. „URLs ohne Endung“ probiert path.html und path/index.html, wenn eine Datei fehlt (für VitePress und ähnliche Generatoren, wie nginx try_files $uri $uri.html $uri/index.html). „404-Seite“ ist ein Pfad innerhalb des Verzeichnisses, etwa 404.html, der mit Status 404 ausgeliefert wird
Fester Text	Eigener Inhalt, Content-Type (Standard text/plain; charset=utf-8) und Statuscode (100-599, Standard 200)

Weitere Optionen für Reverse-Proxy-Sites:

• Backend-Host verwenden: Der Host-Header wird auf die Backend-Adresse geändert; ist die Option aus, bleibt der Host der Client-Anfrage erhalten;
• Prüfung des Backend-Zertifikats überspringen, Keep-Alive deaktivieren;
• PROXY-Protokoll an das Backend senden (v2-Header, reicht die echte Client-IP durch, setzt Unterstützung durch das Backend voraus);
• X-Forwarded-For / X-Forwarded-Proto / X-Forwarded-Host / X-Forwarded-Port und X-Real-IP hinzufügen;
• Aufgerufene Domain als SNI verwenden (nur HTTPS-Backends): Der Handshake trägt die vom Besucher verwendete Domain, und das Zertifikat wird dagegen geprüft, wie bei nginx proxy_ssl_server_name on; proxy_ssl_name $host. Aktivieren Sie die Option, wenn das Backend nach SNI routet, zum Beispiel bei vhost_https von frp. Jedes Backend hat seinen eigenen Verbindungspool, daher werden Verbindungen nie domainübergreifend wiederverwendet.

Sites jedes Typs können ein Zugriffslog, Cross-Origin (CORS) sowie eigene Request- und Response-Header festlegen (je Zeile ein Key: Value; ein leerer Value entfernt den Header) und auf eine Instanz der WAF-Firewall verweisen (existiert die Instanz nicht oder ist sie deaktiviert, werden Anfragen durchgelassen).

Transport und Protokolle

• HTTPS: nutzt ein Zertifikat aus dem Modul SSL-Zertifikate, das die Domain abdeckt;
• HTTP/3 (QUIC): wird in einem Listener mit aktiviertem HTTPS eingeschaltet; HTTP/3 wird dann zusätzlich per UDP auf derselben Portnummer bereitgestellt und Browsern über den Antwort-Header Alt-Svc angekündigt. Der UDP-Port muss in Firewall und Portweiterleitung freigegeben sein;
• WebSocket: wird vom Reverse Proxy automatisch unterstützt;
• PROXY-Protokoll: Ein Listener kann PROXY-Header akzeptieren, die vorgelagerte Komponenten (wie haproxy und frp) senden. Er vertraut nur den IPs oder Subnetzen unter „Globale Einstellungen → Vertrauenswürdige PROXY-Quellen“; bleibt die Liste leer, wird keiner Quelle vertraut. Der Reverse Proxy kann PROXY-Header an das Backend senden.

Authentifizierung

Konfigurieren Sie sie auf der Seite „Sicherheit“ des Site-Editors:

• Web-Authentifizierung: Der Browser zeigt eine Anmeldeseite;
• Basic-Authentifizierung: HTTP Basic;
• Benutzer: je Zeile ein username:password, das Passwort kann ein bcrypt-Hash sein. Die Basic-Authentifizierung braucht bei Aktivierung mindestens einen Benutzer; die Web-Authentifizierung braucht bei Aktivierung mindestens einen Benutzer oder eine Identität der Anmeldung über Drittanbieter;
• Anmeldung über Drittanbieter: GitHub, Google, QQ und OIDC werden unterstützt, mit Ihren eigenen OAuth-Apps. Erlaubte Identitäten stehen je Zeile in der Form provider:account, zum Beispiel github:octocat und google:me@gmail.com. Ein # am Zeilenende fügt einen Kommentar hinzu, und github:* bedeutet jedes Konto dieses Anbieters.

Die Anbieter für die Anmeldung über Drittanbieter werden in den „Globalen Einstellungen“ konfiguriert: Tragen Sie Ihre eigene Client-ID / Secret ein und aktivieren Sie den Anbieter, und legen Sie außerdem eine Callback-Adresse fest (sie muss von einem Listener von Gately bedient werden, zum Beispiel https://auth.example.com). Die bei GitHub / Google / QQ zu registrierende Callback-URL lautet:

https://auth.example.com/__gately_auth/oauth/callback

Die Anmeldung über Drittanbieter für die Verwaltungsoberfläche selbst wird separat unter „Einstellungen → Konto & Sicherheit“ konfiguriert.

Forward-Auth (Authelia und Ähnliches)

Übergeben Sie die Authentifizierung an einen externen Dienst, wie nginx auth_request oder Traefik forwardAuth. Aktivieren Sie „Forward-Auth“ auf der Seite „Sicherheit“. Die Option lässt sich auf derselben Site nicht mit Basic- oder Web-Authentifizierung kombinieren.

Feld	Beschreibung
url	Der Prüf-Endpunkt, etwa http://127.0.0.1:9091/api/authz/auth-request von Authelia
loginUrl	Wohin Besucher geschickt werden, wenn der Endpunkt mit 401 antwortet, etwa https://auth.example.com/?rd={url}&rm={method}. {url} ist die ursprüngliche Adresse (URL-kodiert) und {method} die Anfragemethode. Ist das Feld leer, wird die Antwort des Endpunkts unverändert zurückgegeben
copyHeaders	Identitäts-Header, die aus der Antwort des Endpunkts in die Backend-Anfrage kopiert werden; Standard sind Remote-User, Remote-Groups, Remote-Email und Remote-Name

So funktioniert es:

• Jede Anfrage geht zuerst als GET ohne Body an url, mit den Headern des Besuchers (Cookies, Authorization usw.) plus X-Original-Method, X-Original-URL, X-Forwarded-Method, X-Forwarded-Proto, X-Forwarded-Host, X-Forwarded-Uri, X-Forwarded-For und X-Real-Ip. Das Timeout beträgt 10 Sekunden;
• Eine 2xx-Antwort lässt die Anfrage mit den hinzugefügten Identitäts-Headern durch; ein 401 leitet auf loginUrl um (Status 302); andere Antworten wie 403 oder eine Weiterleitung gehen an den Besucher zurück; ein nicht erreichbarer Dienst ergibt 502;
• Von Besuchern gesendete Identitäts-Header werden immer entfernt, sie lassen sich also nicht fälschen;
• Es funktioniert mit Pfadregeln und dem „Authentifizierungsbereich“, sodass nur manche Pfade (zum Beispiel /admin) eine Anmeldung brauchen, sowie mit temporären Freigabelinks.

Gemeinsame Benutzer: TOTP und Single Sign-on

Legen Sie Konten einmal an und nutzen Sie sie auf mehreren Sites, optional mit TOTP-Zwei-Faktor-Prüfung. Das deckt ab, wofür viele Authelia betreiben.

Unter „Globale Einstellungen → Gemeinsame Benutzer“:

• Fügen Sie Benutzer mit Benutzername und Passwort hinzu. Passwörter werden als bcrypt-Hashes gespeichert und nie von der API zurückgegeben. Für TOTP klicken Sie auf „TOTP aktivieren“, scannen den QR-Code mit einer Authenticator-App (Google Authenticator, 1Password usw.) und speichern. Ein neu erzeugter Schlüssel macht den alten ungültig;
• SSO-Domain, etwa example.com: Nach der Anmeldung auf einer beliebigen Site unter dieser Domain oder ihren Subdomains brauchen die anderen Sites dort keine weitere Anmeldung. Dafür dient ein Cookie auf der übergeordneten Domain (gately_sso, 7 Tage gültig), das nie an Backends weitergereicht wird. Leer lassen, um sich auf jeder Site einzeln anzumelden.

Aktivieren Sie bei einer Site neben der Web- oder Basic-Authentifizierung „Gemeinsame Benutzer verwenden“. Die eigenen Benutzer der Site funktionieren weiterhin.

Verhalten:

• Die Anmeldeseite zeigt ein Feld für den Prüfcode, sobald ein gemeinsamer Benutzer TOTP hat. Jeder Code gilt nur einmal;
• Ändert sich Passwort oder TOTP-Schlüssel eines Benutzers, werden dessen Sitzungen beendet;
• Die Basic-Authentifizierung akzeptiert nur gemeinsame Benutzer ohne TOTP, weil eine Passwortabfrage des Browsers keine Möglichkeit bietet, einen Code einzugeben;
• Fehlgeschlagene Versuche zählen für dieselbe Ratenbegrenzung und automatische Sperre wie andere Anmeldungen.

Zugriffskontrolle

IP-Allowlist und -Blocklist

„IP-Zugriffskontrolle“ auf der Seite „Sicherheit“ der Site kann aus, Allowlist oder Blocklist sein. Die Liste nimmt je Zeile eine IP oder ein Subnetz auf (etwa 192.168.1.0/24); zusätzlich lassen sich abonnierte IP-Listen einbinden.

Abonnierte IP-Listen

Legen Sie Listen unter „Globale Einstellungen → Abonnierte IP-Listen“ an: Geben Sie die URL und das Aktualisierungsintervall an (standardmäßig 24 Stunden). Gately lädt die Liste regelmäßig herunter und speichert sie im Konfigurationsverzeichnis, sodass sie nach einem Neustart auch ohne Internetverbindung verfügbar ist. Der Inhalt enthält je Zeile eine IP, ein CIDR oder einen Bereich Start-Ende; alles nach #, ; oder // gilt als Kommentar. IP-Bereiche chinesischer Provinzen und Städte liefert etwa metowolf/iplist, zum Beispiel https://metowolf.github.io/iplist/data/cncity/440000.txt (Provinz Guangdong).

• Allowlist und Blocklist von Sites und Pfadregeln können mehrere Listen verwenden; sie werden zusammen mit den manuell eingetragenen Bereichen geprüft, ein Treffer in einem beliebigen Eintrag genügt;
• Lässt sich der heruntergeladene Inhalt nicht lesen (etwa weil eine Fehlerseite zurückkam), bleibt die vorherige Liste erhalten, der Grund wird an der Liste angezeigt und nach einer Stunde erneut versucht;
• Bis eine Liste erfolgreich heruntergeladen ist, gilt sie als leer: Eine Allowlist verweigert dann den Zugriff, eine Blocklist sperrt nichts zusätzlich;
• Listen, die noch von einer Site verwendet werden, lassen sich nicht löschen.

Pfadregeln

Überschreiben Sie unter „Pfadregeln“ auf der Seite „Sicherheit“ die Authentifizierungs- und IP-Einstellungen der Site nach Pfadpräfix:

Feld	Werte
prefix	Ein Pfadpräfix, das mit / beginnt, etwa /admin
auth	Von der Site erben (leer), off (keine Authentifizierung), on (Authentifizierung erforderlich)
ipMode / ipList	Von der Site erben (leer), whitelist oder blacklist, mit einer Liste von IPs oder Subnetzen

Zuordnungsregeln:

• Das längste Präfix gewinnt;
• Die Zuordnung folgt den Grenzen von Pfadsegmenten: /admin trifft /admin und /admin/x, aber nicht /administrator;
• Der Anfragepfad wird zuerst normalisiert (., .. und doppelte Schrägstriche werden entfernt) und dann abgeglichen, daher wird /public/../admin als /admin behandelt;
• Für dasselbe Präfix lässt sich nur eine Regel konfigurieren.

Die Option „Authentifizierungsbereich“ (authOptional): Ist sie angekreuzt, gilt die Authentifizierung nur für Pfade, die in den Regeln als „Erforderlich“ markiert sind, alle anderen Pfade sind öffentlich. Für diese Option muss zuerst die Basic- oder Web-Authentifizierung aktiviert sein.

Temporäre Freigabelinks

Ist die Basic- oder Web-Authentifizierung aktiviert, können Sie für eine Site Freigabelinks erstellen, damit Besucher ohne Konto zugreifen können:

Feld	Beschreibung
Name	Eine Bezeichnung, etwa „Für Alice“
Ablauf	Leer lassen für keinen Ablauf
Nutzungen maxUses	Maximale Anzahl, wie oft der Link eingelöst werden kann; 0 bedeutet unbegrenzt. Der Zähler wird nach einem Neustart zurückgesetzt
Pfadbeschränkung pathPrefix	Ist das Feld nicht leer, kann der Link nur auf Pfade unter diesem Präfix zugreifen; es muss mit / beginnen

Ein Besucher ruft https://domain/beliebiger-pfad?_gs=token auf, um eine Sitzung einzulösen. Nach erfolgreicher Einlösung setzt der Server ein Cookie für den anmeldefreien Zugang und leitet auf die Adresse ohne den Parameter _gs weiter. Die Sitzung gilt höchstens 24 Stunden und nie über den Ablauf des Links hinaus. Ein ungültiges Token wird wie ein normaler Besuch behandelt und verrät den Grund des Fehlschlags nicht. Bereits ausgestellte Sitzungen werden sofort ungültig, sobald der Link gelöscht wird. Das Token wird nach dem Speichern erzeugt (mindestens 16 Zeichen), und der vollständige Link lässt sich in der Oberfläche kopieren.

Ratenbegrenzung bei Authentifizierungsfehlern und automatische Sperre

• Nach 10 fehlgeschlagenen Authentifizierungen von derselben Quell-IP innerhalb von 15 Minuten werden weitere Versuche eine Zeit lang abgelehnt;
• Tragen Sie unter „Globale Einstellungen → Automatische Sperre → Sperre bei Authentifizierungsfehlern“ eine Anzahl Minuten ein (0 bis 43200); die Quell-IP wird gesperrt, wenn sie 10 Fehlschläge erreicht. 0 bedeutet keine Sperre, nur Ratenbegrenzung;
• Löst eine automatische Sperre aus, wird ein Ereignis AuthBanned veröffentlicht, das sich über die Benachrichtigungszentrale versenden lässt;
• IPv6-Adressen werden pro /64-Subnetz gezählt und gesperrt.

Sperrliste

Die Sperrliste in den „Globalen Einstellungen“ zeigt die aktuell gesperrten IPs, den Grund (wiederholte Authentifizierungsfehler oder manuelle Sperre) und den Ablaufzeitpunkt, und jeder Eintrag lässt sich mit „Entsperren“ aufheben. Sie können auch manuell sperren: Geben Sie eine IP und eine Anzahl Stunden ein (1 bis 720, also höchstens 30 Tage); die API verwendet standardmäßig 24 Stunden.

Die Sperrliste wird mit dem Einbruchschutz geteilt: Ist dieses Modul eingeschaltet, zeigt dieser Abschnitt nur die Anzahl der Sperren und verweist zur Verwaltung auf dessen Seite. Sperren gelten auch für Portweiterleitung, STUN und andere Dienste und werden bei aktiver Firewall-Synchronisierung in der System-Firewall verworfen; mit „LAN-Adressen ignorieren“ werden LAN-Adressen nie automatisch gesperrt.

GeoIP-Länderfilter

Der „Länderfilter“ einer Site hat drei Modi: aus, nur erlauben und verweigern. Geben Sie zweistellige ISO-Ländercodes kommagetrennt ein, etwa CN, HK, US. Bei Aktivierung ist mindestens ein Land erforderlich.

• Die Filterung hängt von einer GeoIP-Datenbank ab, die Sie zuerst unter „Globale Einstellungen → GeoIP-Datenbank“ importieren müssen: Laden Sie eine .mmdb-Datei hoch oder geben Sie eine Download-URL ein. MaxMind GeoLite2, DB-IP und andere Länder- oder Städte-Datenbanken werden unterstützt; die Upload-Grenze beträgt 129 MB;
• Ist keine Datenbank geladen, hat die Filterung keine Wirkung (alle Besucher passieren) und die Oberfläche zeigt einen Hinweis;
• Adressen privater Netze sind immer erlaubt;
• Im Modus „Verweigern“ werden Adressen erlaubt, deren Land sich in der Datenbank nicht finden lässt.

Backends pro Pfad

Leiten Sie bei einer Reverse-Proxy-Site Anfragen unter einem Pfadpräfix an andere Backends weiter, wie nginx location /api/ { proxy_pass ...; }. Fügen Sie sie unter „Backends pro Pfad“ auf der Seite „Allgemein“ des Site-Editors hinzu.

Feld	Beschreibung
prefix	Ein Pfadpräfix wie /api/. Die Zuordnung folgt den Grenzen von Pfadsegmenten: /api und /api/ treffen beide /api und /api/x, aber nicht /apix
targets	Die Backends für diesen Pfad, in derselben Schreibweise wie die Backends der Site. Ist das Feld leer, werden die Backends der Site verwendet und nur die folgenden Header hinzugefügt
requestHeaders	Für diesen Pfad hinzugefügte Request-Header, je Zeile ein Key: Value. Sie werden nach den Headern der Site angewendet, und ein Header mit gleichem Namen überschreibt den der Site

• Das längste Präfix gewinnt, und der Pfad wird unverändert weitergeleitet (das Präfix wird nicht entfernt);
• Die übrigen Einstellungen der Site, etwa die Host-Option, Zertifikatsprüfung, Forwarded-Header, das PROXY-Protokoll, die Lastverteilungsstrategie und Health-Checks, gelten für jedes Pfad-Backend;
• Kompression, Ratenbegrenzung, Cache und Umschreibungen gelten für die ganze Site.

Erweiterungen für den Reverse Proxy

Diese Optionen finden Sie auf der Seite „Traffic“ des Site-Editors.

Backends, Gewichtung und Backup

Die Backend-Liste nimmt je Zeile eine Adresse auf, optional gefolgt von Parametern:

http://10.0.0.2:8080 weight=3
http://10.0.0.3:8080 backup

• weight=N: Gewichtung, eine ganze Zahl von 1 bis 100, Standard 1;
• backup: ein Standby-Backend, das nur verwendet wird, wenn alle Nicht-Backup-Backends nicht verfügbar sind. Sind alle Backends nicht verfügbar, werden alle Nicht-Backup-Backends erneut versucht.

Strategie der Lastverteilung

Option in der Oberfläche	lbPolicy	Beschreibung
Round Robin (gewichtet)	Leer	Standard
Zufällig (gewichtet)	random
IP-Hash (Sticky Sessions)	ip_hash	Dieselbe Client-IP geht immer an dasselbe Backend
Wenigste Verbindungen	least_conn	Wählt den kleinsten Wert aus Verbindungen / Gewichtung

Health-Checks

Der Schalter für aktive Prüfungen ist standardmäßig aus. Felder und Standardwerte nach dem Aktivieren:

Feld	Standard	Bereich
Modus mode	http	http (fragt den Prüfpfad an; ein Statuscode unter 400 gilt als gesund) oder tcp (testet nur die Verbindung)
Pfad path	/	Beginnt mit /, nur im http-Modus
Intervall interval	10 Sekunden	1 bis 3600
Timeout timeout	3 Sekunden	1 bis 60
Aufeinanderfolgende Fehlschläge fails	3 Fehlschläge markieren es als nicht verfügbar	1 bis 20
Aufeinanderfolgende Erfolge passes	2 Erfolge stellen es wieder her	1 bis 20

Ist das Senden des PROXY-Protokolls an das Backend aktiviert, wechseln HTTP-Prüfungen automatisch auf TCP.

Passive Prüfungen sind immer aktiv: Bei mehreren Backends wird ein Backend nach 3 aufeinanderfolgenden Verbindungsfehlern für 30 Sekunden pausiert und danach erneut geprüft (ein einzelnes Backend ohne aktive Prüfung wird nie entfernt). Sobald aktive Prüfungen aktiviert sind, entscheiden allein die Prüfergebnisse über die Wiederherstellung. Ändert sich der Zustand eines Backends, werden die Ereignisse „Upstream ausgefallen“ und „Upstream wiederhergestellt“ veröffentlicht, die sich über die Benachrichtigungszentrale versenden lassen.

Kompression

Die Kompression lässt sich für Reverse-Proxy-, Statische-Dateien- und Fester-Text-Sites aktivieren (nicht für Weiterleitungs-Sites). Anhand von Accept-Encoding wird br bevorzugt, danach gzip.

• Nur textartige Inhalte werden komprimiert: text/*, JSON, JavaScript, XML, XHTML, RSS / Atom, WebAssembly und SVG; text/event-stream ist ausgenommen;
• Antworten, deren deklarierte Content-Length unter 256 Bytes liegt, bleiben unverändert;
• Antworten, die bereits ein Content-Encoding haben, bleiben unverändert; WebSocket-Upgrade-Anfragen werden direkt durchgereicht;
• Nach der Kompression werden starke ETags in schwache ETags umgewandelt.

Ratenbegrenzung pro IP

Token-Bucket-Ratenbegrenzung pro Client-IP. Felder:

Feld	Beschreibung
rate	Erlaubte Anfragen pro Sekunde
burst	Burst-Kapazität. Ist rate gesetzt und burst gleich 0, gilt als Standard rate abgerundet plus 1
maxConns	Maximale gleichzeitige Anfragen pro IP; 0 bedeutet unbegrenzt

Ist die Ratenbegrenzung aktiviert, muss mindestens eines von rate und maxConns gesetzt sein.

Antwort-Cache im Arbeitsspeicher

Gilt nur für Reverse-Proxy-Sites. Der Cache liegt im Arbeitsspeicher und verdrängt nach LRU.

Feld	Standard	Bereich
ttl Standarddauer	0	0 bis 30 Tage (in Sekunden). Deklariert der Upstream keine Cache-Direktive, werden 200er-Antworten so lange gecacht; 0 bedeutet, dass nur Antworten gecacht werden, die der Upstream ausdrücklich erlaubt
maxMb Cache-Kapazität	64	1 bis 4096 MB

Cache-Regeln:

• Nur GET-Anfragen werden gecacht, und die Anfrage darf weder die Header Authorization, Cookie oder Range noch Cache-Control: no-cache enthalten;
• Nur Antworten mit Status 200 werden gecacht; eine Antwort wird übersprungen, wenn sie Set-Cookie, Vary: * oder ein Cache-Control von no-store / private / no-cache enthält;
• s-maxage wird zuerst berücksichtigt, danach max-age;
• Ein einzelner Eintrag ist auf 4 MB und zugleich auf höchstens ein Viertel der Gesamtkapazität begrenzt;
• Ein Treffer liefert die Header X-Cache: HIT und Age, ein Fehlschlag liefert X-Cache: MISS;
• Der Cache-Schlüssel enthält Host, die vollständige Anfrage-URI und Accept-Encoding.

Pfad umschreiben und weiterleiten

Regeln werden der Reihe nach abgeglichen, und beim ersten Treffer endet der Abgleich.

Feld	Beschreibung
pattern	Ein regulärer Ausdruck, der gegen den Anfragepfad abgeglichen wird, etwa ^/old/(.*)$
to	Das Ersetzungsergebnis; mit $1 verweisen Sie auf Gruppen
redirect	Aus für ein internes Umschreiben (der umgeschriebene Pfad wird an das Backend gesendet, und das Ziel muss mit / beginnen); an für eine Weiterleitung
code	Statuscode der Weiterleitung 301 / 302 / 307 / 308, Standard 302

Weiterleitungen behalten die ursprünglichen Query-Parameter bei. Ein Weiterleitungsziel darf {host} enthalten, die vom Besucher verwendete Domain. Weiterleitungsregeln laufen vor der Authentifizierung, wie nginx location = / { return 302 ...; }, sodass ein Pfad wie / Besucher weiterschicken kann, ohne dass sie sich anmelden müssen.

Zugriffsstatistik und Monitoring

Site-Statistik

Klicken Sie bei einem laufenden Listener in der Site-Zeile auf „Statistik“, um das Statistikfenster zu öffnen, in dem Sie die letzte 1 Stunde, 6 Stunden oder 24 Stunden wählen können:

• Zugriffsstatistik im Minutentakt: ein Punkt pro Minute, die letzten 24 Stunden aufbewahrt, mit einer Kurve der Anfragezahl sowie 4xx- / 5xx-Fehlerkurven;
• Verteilung der Statuscodes (2xx / 3xx / 4xx / 5xx) und kumulierter Antwort-Traffic;
• Die Top 10 der Quell-IPs und die Top 10 der Länder (für die Länderstatistik ist eine importierte GeoIP-Datenbank nötig);
• Reverse-Proxy-Sites zeigen Health-Status, Gewichtung, Backup-Kennzeichen und aktuelle Verbindungsanzahl jedes Backends.

Die Statistiken liegen im Arbeitsspeicher und beginnen nach einem Neustart oder nach einer Änderung der eigenen Einstellungen des Listeners von vorn. Das Bearbeiten einer Site behält ihre Zähler. Die Ranglisten verfolgen höchstens 5000 verschiedene Quellen.

Prometheus-Metriken

Der globale Metriken-Endpunkt GET /api/metrics fasst die Metriken aller Module zusammen, siehe Monitoring. Der folgende Modul-Endpunkt enthält nur die Metriken der Web-Dienste.

Der Metriken-Endpunkt ist GET /api/webservice/metrics im Prometheus-Textformat und erfordert Anmeldedaten oder ein API-Token.

curl -H "Authorization: Bearer gtl_xxxx" http://localhost:16680/api/webservice/metrics

Metrik	Typ	Beschreibung
gately_site_requests_total	counter	Kumulierte Anfragen einer Site
gately_site_errors_total	counter	Backend-Fehler einer Site
gately_site_active_requests	gauge	Laufende Anfragen
gately_site_response_bytes_total	counter	Kumulierte Antwort-Bytes
gately_site_responses_total	counter	Antworten, gezählt nach Statusklasse (Label class: 2xx bis 5xx)
gately_upstream_up	gauge	Ob ein Backend gesund ist: 1 gesund, 0 nicht verfügbar (mit Label upstream)

Alle Metriken tragen die Labels listener (Listener-Name#Listener-Schlüssel) und site (Site-Name oder, falls unbenannt, die erste Domain).

nginx-Konfiguration importieren

Mit „nginx importieren“ oben auf der Seite lassen sich bestehende nginx-Sites in Listener und Sites von Gately umwandeln. Empfohlen ist, auf dem nginx-Host nginx -T auszuführen und die vollständige Ausgabe einzufügen: Sie enthält alle per include eingebundenen Dateien, und Gately löst die includes genauso auf wie nginx.

• Zuerst die Vorschau: Gruppiert nach Port zeigt sie für jede Site Typ, Backend oder Verzeichnis, Quelldatei mit Zeilennummer und Punkte, die Aufmerksamkeit brauchen (Direktiven mit Variablen, Regex-locations, Domains ohne Zertifikat usw.); bei Sites, die sich nicht umwandeln lassen, wird der Grund genannt;
• Sites auf einem bereits vorhandenen Port werden dem bestehenden Listener hinzugefügt, sonst entsteht ein neuer Listener; vorhandene Domains werden übersprungen, sodass sich der Import wiederholen lässt;
• Standardmäßig wird deaktiviert importiert, damit Sie parallel zu nginx eine Site nach der anderen prüfen und dann aktivieren können. Mit „Nach dem Import sofort aktivieren“ gilt alles sofort (belegt nginx denselben Port noch, startet ein neuer Listener nicht);
• Umgewandelt werden: proxy_pass (einschließlich Gewichtung, Backup und Lastverteilungsstrategie aus upstream), statische Verzeichnisse per root / alias (autoindex, try_files $uri.html, error_page 404), Weiterleitungen und feste Inhalte per return, seitenweite rewrite-Weiterleitungen, add_header, proxy_set_header, gzip, allow / deny, Backends, Zugriffskontrolle und Weiterleitungen pro location sowie listen ... proxy_protocol und quic;
• auth_request wird zu Forward-Auth: Die Authentifizierungsadresse stammt aus dem proxy_pass der location für die Auth-Subanfrage (set-Variablen werden unterstützt), die Anmeldeweiterleitung aus error_page 401 =302; gängige Authelia-Konfigurationen lassen sich direkt übernehmen. Ist es nur in einzelnen locations aktiv, wird daraus eine Authentifizierung nur für die betreffenden Pfade;
• auth_basic wird zu Basic-Authentifizierung mit gemeinsamen Benutzern. Die Benutzerdatei von nginx wird nicht gelesen; bis Sie Benutzer anlegen, kommt niemand durch;
• TCP/UDP-Weiterleitungen aus stream richten Sie in der Portweiterleitung ein. Zertifikate werden nicht importiert: Fehlt einer HTTPS-Site ein Zertifikat, nennt die Vorschau die von nginx verwendeten Zertifikatsdateien, die Sie auf der Seite Zertifikate per Dateipfad hinzufügen können.

haproxy und nginx ersetzen

Portweiterleitung und Web-Dienste zusammen können ein Paar aus haproxy und nginx ersetzen. Ein gängiges Layout: eine Regel mit SNI-Routing auf Port 443, die VPN und andere TLS-Dienste direkt an ihre Backends und alles andere an einen Listener der Web-Dienste schickt, der das PROXY-Protokoll akzeptiert; dazu ein Listener der Web-Dienste auf Port 80 mit einer Weiterleitungs-Site (https://{host}).

nginx-Einstellungen umsetzen:

nginx	Gately
server mit server_name	eine Site mit diesen Domains
location mit abweichendem proxy_pass	Backends pro Pfad
auth_request (Authelia)	Forward-Auth oder gemeinsame Benutzer mit TOTP
proxy_ssl_name $host	aufgerufene Domain als SNI verwenden
return 301 https://$host$request_uri	eine Weiterleitungs-Site mit https://{host} und „Pfad und Query beibehalten“
return 302 /admin in location = /	ein Umschreiben mit aktivierter „Weiterleitung“, Muster ^/$
try_files $uri $uri.html $uri/index.html und error_page 404	statische Dateien mit „URLs ohne Endung“ und „404-Seite“
add_header	Antwort-Header

Hinweis zur Bereitstellung

Web-Dienste müssen auf Ports des Hosts wie 80 / 443 lauschen. Bei Docker-Bereitstellungen empfehlen wir --network host.