Jedna z najczęściej używanych przeze mnie funkcji serwera webowego NGINX to Reverse Proxy.
Większość devopsów używa tego do kierowania ruchu na własne Dockery, ale ja wykorzystuję to w jeszcze innym celu.
Jakim? 🧵 ↓
Nie każda usługa SaaS, z której korzystam, oferuje możliwość podpięcia własnej domeny. Niektóre z nich od lat informują, że "pracują nad taką opcją" — a niech sobie pracują, ale ja umiem to na własne potrzeby ogarnąć w kilka minut 🤷♂️
Klasyczna konfiguracja proxy polega na tym, że ruch wychodzący z serwera przechodzi przez jeden, centralny serwer (proxy) i później kierowany jest w świat.
Podejście "Reverse proxy" polega na tym, że ruch "ze świata" kierowany jest przez nasz serwer do pewnego miejsca.
Chcąc podpiąć własną domenę do zewnętrznej usługi, instaluję NGINX np. na własnym serwerze VPS, a następnie w konfiguracji usługi wrzucam te kilka linijek podanych poniżej (te są podstawowe).
To sprawia, że gdy wchodzę na moją domenę, NGINX łączy się z backendem, ale NIE przekazuje prawdziwego hostname podanego przez usera (a więc mojej domeny), a podmienia nagłówek "Host" na taki, aby serwer docelowy myślał, że odwiedzam go, korzystając z prawdziwej domeny.
Testowałem tę metodę na dodawaniu własnej domeny do Notion.
Co ciekawe, NIE działało poprawnie, a to dlatego, że niektóre serwisy zaszywają w źródłe strony swoje nazwy domenowe, więc nałożenie na nie nowej domeny nie tylko powoduje błędy CORS, ale też rozwala cały design.
Rozwiązaniem tego problemu jest moduł "sub_filter" (sub podchodzi od słowa "substitute", a nie "subdomain"). Pozwala on w locie podmieniać teksty w źródłach odebranych przez Reverse Proxy.
Wprowadziłem to rozwiązanie jakieś 2 lata temu na hostingu Mikrus.
Działa idealnie 👍
Jeśli chcesz nauczyć się podstaw konfiguracji serwera NGINX (w tym i modułów do reverse proxy, substitute i kilku innych), to rzuć okiem tutaj:
nginx.mikr.us/
Prawdopodobnie nie znajdziesz bardziej skondensowanej pigułki wiedzy na ten temat.