Vor einiger Zeit habe ich über einen Reverse Proxy mit Apache geschrieben. Das klappt natürlich auch bei Nginx. Es wird dazu das Modul ngx_http_proxy_module benötig. Da es zu den Standards gehört ist es eigentlich immer mit dabei und wird auch automatisch beim kompilieren gebaut.
Es hat eine ganze Reihe von Optionen, aber die wichtigste ist mit Sicherheit proxy_pass. Alle Optionen werden im location { … } Kontext gesetzt.
Ein einfaches Beispiel wie man es im server { … } Kontext verwenden kann.
location /feed {
proxy_pass https://problempod.de/feed/mp3;
proxy_pass_request_headers off;
proxy_pass_request_body off;
proxy_ssl_verify on;
proxy_ssl_trusted_certificate /etc/ssl/certs/ca-certificates.crt;
resolver 8.8.8.8 ipv6=off;
}
Das Ganze ist etwas einfacher als bei Apache. Der Inhalt von „https://problempod.de/feed/mp3“ wird durch den Proxy unter meiner Domain und /feed bereitgestellt. Man kann bei proxy_pass mit http oder https URLs arbeiten. Die beiden Optionen proxy_pass_request_headers und proxy_pass_request_body mit dem Wert „off“ verhindern das irgendwelche Request Informationen des Clients an das Proxy Ziel weiter gegeben werde. Das ist kein muss und manchmal möchte man auch Information vom Client mit geben. Oder gar eigene Header senden. Bei diesem einfachen Beispiel ist das aber nicht der Fall.
Bei https URLs in proxy_pass kann es Sinn machen das Zertifikat zu überprüfen. Bei Default würde Nginx einfach alles akzeptieren. Das kann bei internen Seiten gut und wichtig sein. Aber wenn das Ziel valide Zertifikate verwendet, kann man diese auch überprüfen. Das geht mit proxy_ssl_verify und dem Wert „on“. Das alleine reicht aber nicht. Nginx braucht auch eine Liste mit vertrauenswürdigen Zertifikaten. Diese übergibt man mit proxy_ssl_trusted_certificate „/pfad/zum/cert“. Auf vielen System gibt es mit „/etc/ssl/certs/ca-certificates.crt“ solche eine Liste. Diese enthält oft alle vertrauenswürdigen Zertifikate. Man kann das auch etwas eingrenzen wenn man die CA des Zieles kennt. Zum Beispiel mit „/etc/ssl/certs/COMODO_RSA_Certification_Authority.pem“. Falls die Überprüfung zu einem negativen Ergebnis kommt, wird das als Error ins Log geschrieben und man erhält einen 502 Bad Gateway.
Die resolver Option ist vielseitig einsetzbar. Diese Option gehört streng genommen nicht zu den Proxy Optionen aber kann hier hilfreich sein. Sie definiert wie Nginx an die IP Adresse der Domain in proxy_pass kommt. In diesem Beispiel geht der DNS Request an Googles DNS. Man kann aber auch jeden beliebigen DNS Resolver wählen. Mit dem „ipv6=off“ Wert kann verhindert werden das neben dem A auch ein AAAA Abruf gemacht wird. Standardmäßig werden IPv4 und IPv6 Adressen aufgelöst. Das kann helfen wenn das Ziel zwar über einen AAAA Record verfügt aber der nicht zu erreichen ist. Neben einem externen kann auch ein interner DNS Server gewählt werden. Fehlt die resolver Option fällt Nginx auf die OS Einstellungen zurück. In den meisten Fällen wird das der Nameserver in „/etc/resolv.conf“ sein.
Der einfachste Proxy bei Nginx wäre so etwas
location /feed2 {
proxy_pass https://problempod.de/feed/m4a;
}
Das reicht völlig aus. Aber in den meisten fällen möchte man trotzdem von den vielen Option Gebrauch machen um ein best möglichstes Ergebnis zu erhalten.