Ha jól értem a https kibontást a nginx végzi, és titkosítatlan http közlekedik a belső hálón? Jó esetben a http szerver loggolja a kéréseket, ott meg tudod nézni, hogy mit kérnek tőle. Ha az nem loggol, akkor a kéréseket tudod debuggolni akár wireshark-kal is könnyedén, vagy egy loggoló TCP proxyn keresztül. (És akár a nginx is rábírható loggolásra, be lehet kapcsolni valahogy, hogy nagyon részletes logot adjon minden kiszolgálásról. Ez a legésszerűbb talán használni, mert ez az eszköz minden hasonló esetben hasznos lesz, ha egyszer megismered a használatát.) "Szabad szemmel" kiolvasható, hogy mi történik. A legvalószínűbb, hogy az URI lesz olyanra átírva, amire a http szerver - jogosan - azt mondja, hogy olyan nem létezik.
Itt leírja az URI átírásának a szabályait: http://nginx.org/en/docs/http/ngx_http_proxy_module.html#proxy_pass
Elég bonyolult, fontos az is, hogy a minta végén van-e / és hogy a prox_pass parancs végén van-e / ! Minden számít!
Nálam a location a legtöbb esetben /-re végződik, de őszintén szólva nem tudom már megmondani, hogy miért :-) Itt egy működő példa a játszós jenkinsemhez - de itt az eredeti szolgáltatás is a /jenkins/ path alatt van:
# Nginx configuration specific to Jenkins
# Note that regex takes precedence, so use of "^~" ensures earlier evaluation
location ^~ /jenkins/ {
auth_request /auth;
# Convert inbound WAN requests for https://domain.tld/jenkins/ to
# local network requests for http://10.0.0.100:8080/jenkins/
proxy_pass http://127.0.0.1:8089/jenkins/;
Ha ilyen kontextus path alá akarsz tenni egy weboldalt, az az adott oldalon belüli abszolút linkeket el tudja rontani, ha van benne olyan. Például a HTML-ben van ilyen: <img src="/style/images/mylogo.png"/>, akkor ez a hivatkozás nem a /a/style/images/mylogo.png-re fog mutatni sajnos. Tehát nem elég a headereket átírogatni, de a konkrét HTML tartalomban is meg kell hogy változzanak az abszolút linkek! Ha gondolt erre a weboldal fejlesztője, akkor be lehet valahogy állítani. Ha nem gondolt rá, akkor várhatóan esélytelen: én mostanában játszottam ilyen web szolgáltatásokkal, és ugyan a fejlesztés során gondoltam erre a problémára, mégis rendre benéztem valamit, elsőre sosem működött.
A fenti jenkins példában a Jenkins esetén például magán a Jenkins-en egy konfigurációs paraméter, amit a weben be lehet írni, az adja meg a root URL-t, amin a Jenkins elérhető. Saját http szolgáltatások esetén úgy szoktam megcsinálni, hogy a nginx-től headerben kapja meg a http szerver, hogy mi a saját kontext path-ja: ezzel a trükkel ugyanaz a http szerver több különböző domain alatt is képes működni, és mindegyiken megfelelő választ tud adni, ha úgy van bekonfigurálva.