proxy_redirect NGINX ను మీ VPN హోస్ట్తో కలపదు
proxy_redirect ఇప్పటికే వచ్చిన ప్రతిస్పందనలోని హెడర్లను పునర్లేఖనం చేస్తుంది; అది ఎప్పుడూ upstream ను ఎంచుకోదు. proxy_pass, backend కు మార్గం, తర్వాత హెడర్లను తనిఖీ చేయండి.
పేరులో redirect అనే పదం ఉంది, కాబట్టి VPN వెనుక ఉన్న backend అందుబాటులో లేనప్పుడు అది location block లో అతికించబడుతుంది. ఏమీ మారదు, మరియు స్పష్టమైన ముగింపు ఏమిటంటే ఈ సూచన పాడైంది లేదా వేరే వాక్యనిర్మాణం కావాలి. వాస్తవానికి జరిగినది సరళమైనది మరియు తక్కువ ప్రశంసనీయమైనది: proxy_redirect ఇప్పటికే తిరిగి వచ్చిన ప్రతిస్పందనపై పనిచేస్తుంది, ఈ అమరికలో ఏ అభ్యర్థనా అంత దూరం చేరలేదు.
ఒక అభ్యర్థనలో రెండు సూచనలు, రెండు క్షణాలు
రివర్స్ ప్రాక్సీ ద్వారా వెళ్లే HTTP అభ్యర్థన క్రమంగా అనేక నిర్ణయాల గుండా వెళుతుంది, రెండు సూచనలు ఆ క్రమం యొక్క వ్యతిరేక చివరల్లో ఉంటాయి. ఒకటి అభ్యర్థన ఎక్కడికి వెళ్తుందో ఎంచుకుంటుంది. మరొకటి తిరిగి వచ్చే ప్రతిస్పందనలో కొన్ని హెడర్లను సవరిస్తుంది.
| 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 |
ఆ క్రమమే మొత్తం సమాధానం. మొదటి పంక్తి విఫలమైనందున రెండవ పంక్తి ఎప్పుడూ అమలు కాకపోతే, రెండవ సూచన తప్పుగా కాన్ఫిగర్ చేయబడలేదు, అది కేవలం అందుబాటులో లేదు. రెండవ పంక్తిని ఎంత మళ్లీ రాసినా, అది సవరించవలసిన ప్రతిస్పందన ఉత్పన్నం కాదు. మొదటి పంక్తి నుండి బయటకు నిర్ధారణ చేయండి, గందరగోళ ప్రవర్తన తప్పిపోయిన మార్గం లేదా తిరస్కరించబడిన కనెక్షన్గా మారుతుంది.
upstream ఎంచుకోవడం proxy_pass పని
NGINX పబ్లిక్ ఎంట్రీ హోస్ట్పై నడుస్తుందని, తన VPN ద్వారా 10.40.0.20:8080 వద్ద ఉన్న అప్లికేషన్ను చేరుకుంటుందని అనుకుందాం. ఆ అప్లికేషన్ను ఎంచుకునే భాగం ఉన్న server block లోపల ఇలా కనిపిస్తుంది:
location / {
proxy_pass http://10.40.0.20:8080;
}నిజమైన స్కీమ్, చిరునామా, పోర్ట్ను ఉపయోగించండి, దీన్ని అమరిక కాదు భాగంగా పరిగణించండి. ఎంట్రీ హోస్ట్ VPN మార్గం, అనుమతించిన ఫార్వార్డింగ్ మార్గం మరియు ఆ సేవకు పనిచేసే తిరిగి ట్రాఫిక్ను కూడా ఉంచుకోవాలి, ఎందుకంటే కాగితంపై చిరునామాను చేరుకునే ప్రాక్సీకి కూడా కెర్నల్ అంగీకారం అవసరం.
proxy మాడ్యూల్ సూచన upstream ఎంపికను ప్రతిస్పందన హెడర్ పునర్లేఖనం నుండి వేరుగా ఉంచుతుంది, మరియు URI ఉన్న proxy_pass విలువ సరిపోలే location ఉపసర్గ ఎలా భర్తీ చేయబడుతుందో మారుస్తుందని గమనిస్తుంది. అప్లికేషన్ ఆశించే URL ను తనిఖీ చేయకుండా మార్గ భాగాలను జోడించడం లేదా తీసివేయడం రూటింగ్ వైఫల్యం లాగా కనిపించే 404ను ఉత్పత్తి చేసే నమ్మదగిన మార్గం.
proxy_redirect ప్రైవేట్ చిరునామాను లీక్ చేసే ప్రతిస్పందనలను సరిచేస్తుంది
ట్రాఫిక్ ప్రవహించడం ప్రారంభమైనప్పుడు, backend తన ప్రైవేట్ చిరునామాను పేర్కొనే Location హెడర్తో సమాధానం ఇవ్వవచ్చు. ఆ హెడర్ను అనుసరించే బ్రౌజర్ పబ్లిక్ ప్రవేశ బిందువును విడిచిపెట్టి, పరిష్కరించలేని దాన్ని చేరుకోవడానికి ప్రయత్నిస్తుంది. ఉద్దేశపూర్వకంగా కాన్ఫిగర్ చేసిన ప్రతిస్పందన పునర్లేఖనం ప్రైవేట్ URLను పబ్లిక్పై మ్యాప్ చేస్తుంది:
proxy_redirect http://10.40.0.20:8080/ https://app.example.com/;రెండు వైపులా నిజమైన విలువలతో భర్తీ చేయండి. సన్నని పరిధిని కూడా అర్థం చేసుకోండి: సరిపోలే Location మరియు Refresh హెడర్ల వచనం పునర్లేఖనం చేయబడుతుంది, కానీ HTML, JavaScript లేదా డౌన్లోడ్ చేసిన ఫైళ్లలో పొందుపరిచిన URL కాదు.
అప్లికేషన్ ప్రతిచోటా సంపూర్ణ లింక్లను నిర్మిస్తే, శాశ్వత పరిష్కారం దాని స్వంత బాహ్య-URL కాన్ఫిగరేషన్, ప్రాక్సీపై పెరుగుతున్న పునర్లేఖన నియమాల జాబితా కాదు. అవుట్పుట్ సరిగ్గా కనిపించే వరకు నియమాలను జోడించడం ఎవరూ పరీక్షించని మొదటి పేజీలోనే విఫలమయ్యే కాన్ఫిగరేషన్ను ఉత్పత్తి చేస్తుంది. అప్లికేషన్ యొక్క ఒక సరైన సెట్టింగ్ మొత్తం సేకరణను భర్తీ చేస్తుంది.
హెడర్ పునర్లేఖనం సరిచేయలేనిది
కొన్ని పక్కనున్న సమస్యలు రీడైరెక్ట్ సమస్యల్లా కనిపిస్తాయి కానీ కావు. upstream కు పంపే Host హెడర్ backend యొక్క వర్చువల్ హోస్ట్తో సరిపోలాల్సి ఉండవచ్చు. TLS upstream కు నిర్దిష్ట సర్వర్ పేరు మరియు ధృవపత్ర ధృవీకరణ అవసరం కావచ్చు, ప్రతిస్పందన హెడర్ పునర్లేఖనం రెండింటికీ సహాయం చేయదు.
కుకీ పరిధి మరియు డొమైన్ లక్షణాలు అప్లికేషన్ మరియు దాని కాన్ఫిగరేషన్కు చెందుతాయి. ప్రాక్సీ రోజంతా హెడర్లను విసిరేయవచ్చు లేదా పునర్లేఖనం చేయవచ్చు, అయినా రెండవ అభ్యర్థనలో విఫలమయ్యే సెషన్ను ఉత్పత్తి చేస్తుంది, ఎందుకంటే కుకీ బ్రౌజర్ ఎప్పుడూ సందర్శించని హోస్ట్కు జారీ చేయబడింది. ఆ వైఫల్యం అడపాదడపా కనిపిస్తుంది, అందుకే టికెట్ క్యూలో అంత కాలం నిలిచి ఉంటుంది. కుకీ డొమైన్ను చదవడం సాధారణంగా ఒక నిమిషంలో విచారణను ముగిస్తుంది.
ప్రామాణీకరణ మరియు backend ఎంపికను కూడా ఉద్దేశించిన అప్లికేషన్కు పరిమితం చేయండి. పబ్లిక్ రివర్స్ ప్రాక్సీ సర్వర్ VPN ద్వారా ఒకే అప్లికేషన్ను బహిర్గతం చేయాలి, ఆ హోస్ట్ చేరుకోగల ప్రతి ప్రైవేట్ చిరునామాకు సాధారణ గేట్వేగా మారడం బదులు. కాలర్ అడిగిన ప్రతిదాన్ని పంపే ఒకే సాధారణ location ఒక బహిర్గత సేవను మీ ప్రైవేట్ నెట్వర్క్ మ్యాప్గా మారుస్తుంది. upstreamను స్పష్టంగా పేర్కొని అక్కడే ఉంచండి.
అభ్యర్థన ప్రయాణించే క్రమంలోనే పరీక్షించండి
క్రమంగా మూడు విషయాలను నిర్ధారించండి: NGINX ఉద్దేశించిన locationను ఎంచుకుంది, backend కు అభ్యర్థనను పూర్తి చేసింది, బ్రౌజర్ తర్వాత వచ్చే ఏ రీడైరెక్ట్నైనా అనుసరించి ఉపవనరులను లోడ్ చేసింది. ప్రతి దశకు దాని సొంత లాగ్ పంక్తులు ఉన్నాయి, వాటిని క్రమంలో చదవడం అస్పష్టమైన 502ను నిర్దిష్ట కనుగొనడంగా మారుస్తుంది.
మీకు అవసరమైన భేదం విఫలమైన upstream కనెక్షన్ మరియు చేరుకోలేని ప్రైవేట్ పేరుకు పంపబడిన బ్రౌజర్ మధ్య ఉంది. మొదటిది ప్రాక్సీ లోప లాగ్లో కనిపిస్తుంది; రెండవది ఎప్పుడూ రాని అభ్యర్థనగా కనిపిస్తుంది, బ్రౌజర్ పరిష్కరించలేని హోస్ట్ గురించి ఫిర్యాదు చేస్తుంది. రెండు వేర్వేరు సమస్యలు, రెండు వేర్వేరు ఫైళ్లు, వాటిలో ఒకటి మాత్రమే proxy_redirectతో సంబంధం కలిగి ఉంది.