proxy_redirect verbindt NGINX niet met je VPN-host
proxy_redirect herschrijft headers in een antwoord dat al is aangekomen; het kiest nooit de upstream. Controleer proxy_pass, de route naar de backend en dan de headers.
De naam bevat het woord redirect, dus het wordt in een location-blok geplakt wanneer een backend achter de VPN niet bereikbaar is. Er verandert niets, en de voor de hand liggende conclusie is dat de richtlijn kapot is of andere syntaxis nodig heeft. Wat er werkelijk gebeurde, is eenvoudiger en minder vleiend: proxy_redirect werkt op een antwoord dat al is teruggekomen, en in deze uitrol kwam geen enkel verzoek ooit zo ver.
Twee richtlijnen, twee momenten in één verzoek
Een HTTP-verzoek via een omgekeerde proxy doorloopt meerdere beslissingen op volgorde, en de twee richtlijnen staan aan tegenovergestelde uiteinden van die reeks. De ene kiest waar het verzoek heen gaat. De andere bewerkt bepaalde headers in het antwoord dat terugkomt.
| Directive | When it acts | What it can change |
|---|---|---|
proxy_pass | Before any bytes leave the proxy | Which upstream receives the request |
proxy_redirect | After the upstream responds | Matching Location and Refresh text |
Die volgorde is het hele antwoord. Als de tweede regel nooit wordt uitgevoerd omdat de eerste is mislukt, is de tweede richtlijn niet verkeerd geconfigureerd, hij is simpelweg onbereikbaar. Hoe vaak je de tweede regel ook herschrijft, het antwoord dat hij moest bewerken ontstaat niet. Diagnosticeer van de eerste regel naar buiten, en het verwarrende gedrag lost op in een ontbrekende route of een geweigerde verbinding.
De keuze van de upstream hoort bij proxy_pass
Stel dat NGINX op een openbare ingangshost draait en via zijn VPN een applicatie op 10.40.0.20:8080 kan bereiken. Het fragment dat die applicatie kiest ziet er zo uit, binnen een bestaand server-blok:
location / {
proxy_pass http://10.40.0.20:8080;
}Gebruik het echte schema, adres en poort, en behandel dit als een fragment en niet als een uitrol. De ingangshost moet ook de VPN-route, een toegestaan doorstuurpad en werkend retourverkeer naar die dienst vasthouden, want een proxy die een adres op papier bereikt, heeft nog steeds de instemming van de kernel nodig.
De referentie van de proxy-module houdt de keuze van de upstream gescheiden van het herschrijven van antwoordheaders, en merkt op dat een proxy_pass-waarde met een URI verandert hoe het bijpassende location-prefix wordt vervangen. Padcomponenten toevoegen of verwijderen zonder de URL te controleren die de applicatie verwacht, is een betrouwbare manier om een 404 te produceren die op een routeringsfout lijkt.
proxy_redirect repareert antwoorden die een privéadres lekken
Zodra het verkeer stroomt, kan een backend antwoorden met een Location-header die zijn privéadres noemt. Een browser die die header volgt, verlaat het openbare ingangspunt en probeert iets te bereiken dat hij niet kan oplossen. Een bewust geconfigureerde antwoordherschrijving mapt de privé-URL op de openbare:
proxy_redirect http://10.40.0.20:8080/ https://app.example.com/;Vervang beide kanten door echte waarden. Begrijp ook de smalle reikwijdte: overeenkomende tekst van de headers Location en Refresh wordt herschreven, maar URL's die in HTML, JavaScript of gedownloade bestanden zijn ingebed niet.
Als een applicatie overal absolute links bouwt, is de duurzame oplossing de eigen configuratie voor externe URL's, niet een groeiende lijst herschrijfregels op de proxy. Regels toevoegen tot de uitvoer er goed uitziet, levert een configuratie op die faalt op de eerste pagina die niemand heeft getest. Eén juiste instelling van de applicatie vervangt de hele verzameling.
Wat een header-herschrijving niet kan repareren
Verschillende naburige problemen lijken op redirect-problemen en zijn dat niet. De Host-header die naar de upstream gaat, moet mogelijk overeenkomen met de virtuele host van de backend. Een TLS-upstream kan een specifieke servernaam plus certificaatverificatie vereisen, en het herschrijven van een antwoordheader helpt bij geen van beide.
Cookiebereik en domeinattributen horen bij de applicatie en haar configuratie. Een proxy kan de hele dag headers weggooien of herschrijven en toch een sessie opleveren die bij het tweede verzoek faalt, omdat de cookie is uitgegeven voor een host die de browser nooit heeft bezocht. Die fout lijkt sporadisch, en daarom overleeft hij zo lang in een ticketsysteem. Het domein van de cookie lezen beëindigt het onderzoek meestal binnen een minuut.
Houd ook authenticatie en de keuze van de backend beperkt tot de bedoelde applicatie. Een openbare omgekeerde proxy hoort één applicatie via de VPN van de server beschikbaar te stellen in plaats van een algemene poort te worden naar elk privéadres dat die host kan bereiken. Eén generiek location dat alles doorstuurt wat de aanroeper vraagt, verandert één blootgestelde dienst in een kaart van je privénetwerk. Noem de upstream expliciet en houd hem daar.
Test in de volgorde waarin het verzoek reist
Bevestig drie dingen achter elkaar: NGINX koos het bedoelde location, rondde een verzoek aan de backend af, en de browser volgde elke latere omleiding en laadde de subbronnen. Elke stap heeft zijn eigen logregels, en ze in volgorde lezen maakt van een vage 502 een concrete bevinding.
Het onderscheid dat je nodig hebt, is tussen een mislukte upstream-verbinding en een browser die naar een onbereikbare privénaam is gestuurd. Het eerste verschijnt in het foutenlog van de proxy; het tweede verschijnt als een verzoek dat nooit aankomt, terwijl de browser klaagt over een host die hij niet kan oplossen. Twee verschillende problemen, twee verschillende bestanden, en slechts één van beide heeft überhaupt met proxy_redirect te maken.