proxy_redirect NGINX-ஐ உங்கள் VPN host-உடன் இணைக்கவில்லை
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 ஒரு பொது நுழைவு host-இல் இயங்கி, அதன் VPN வழியாக 10.40.0.20:8080-இல் உள்ள பயன்பாட்டை அடைகிறது என வைத்துக்கொள்வோம். அந்தப் பயன்பாட்டைத் தேர்ந்தெடுக்கும் பகுதி, இருக்கும் server block-க்குள் இப்படித் தெரிகிறது:
location / {
proxy_pass http://10.40.0.20:8080;
}உண்மையான திட்டம், முகவரி, போர்ட்டைப் பயன்படுத்துங்கள், இதைப் பயன்பாடு அல்ல பகுதியாகக் கருதுங்கள். நுழைவு host-ஐ VPN வழி, அனுமதிக்கப்பட்ட அனுப்பு பாதை மற்றும் அந்தச் சேவைக்கான செயல்படும் திரும்பு போக்குவரத்து ஆகியவற்றையும் வைத்திருக்க வேண்டும், ஏனெனில் காகிதத்தில் ஒரு முகவரியை அடையும் ப்ராக்ஸிக்கும் kernel-இன் ஒப்புதல் தேவை.
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-இன் மெய்நிகர் host-உடன் பொருந்த வேண்டியிருக்கலாம். TLS upstream ஒரு குறிப்பிட்ட சேவையகப் பெயரையும் சான்றிதழ் சரிபார்ப்பையும் தேவைப்படுத்தலாம், பதில் தலைப்பை மீளெழுதுவது இரண்டுக்கும் உதவாது.
குக்கி வரம்பும் டொமைன் பண்புகளும் பயன்பாட்டிற்கும் அதன் உள்ளமைவிற்கும் உரியவை. ப்ராக்ஸி நாள் முழுவதும் தலைப்புகளைத் தூக்கி எறியலாம் அல்லது மீளெழுதலாம், இருந்தும் இரண்டாம் கோரிக்கையில் தோல்வியடையும் அமர்வை உருவாக்குகிறது, ஏனெனில் குக்கி உலாவி ஒருபோதும் பார்வையிடாத host-க்கு வழங்கப்பட்டது. அந்தத் தோல்வி இடைவிட்டுத் தோன்றுகிறது, அதனால்தான் டிக்கெட் வரிசையில் இவ்வளவு காலம் நீடிக்கிறது. குக்கியின் டொமைனைப் படிப்பது பொதுவாக ஒரு நிமிடத்தில் விசாரணையை முடிக்கிறது.
அங்கீகாரம் மற்றும் backend தேர்வையும் நோக்கமிடப்பட்ட பயன்பாட்டிற்கு மட்டுப்படுத்துங்கள். பொது தலைகீழ் ப்ராக்ஸி சேவையகத்தின் VPN வழியாக ஒரே பயன்பாட்டை வெளிப்படுத்த வேண்டும், அந்த host அடையக்கூடிய ஒவ்வொரு தனிப்பட்ட முகவரிக்கும் பொது நுழைவாயிலாக மாறுவதற்குப் பதிலாக. அழைப்பவர் கேட்பதை எல்லாம் அனுப்பும் ஒரே பொது location ஒரு வெளிப்படுத்தப்பட்ட சேவையை உங்கள் தனிப்பட்ட வலையமைப்பின் வரைபடமாக மாற்றுகிறது. upstream-ஐ தெளிவாகப் பெயரிட்டு அங்கேயே வைத்திருங்கள்.
கோரிக்கை பயணிக்கும் வரிசையிலேயே சோதியுங்கள்
வரிசையாக மூன்று விஷயங்களை உறுதிப்படுத்துங்கள்: NGINX நோக்கமிடப்பட்ட location-ஐத் தேர்ந்தெடுத்தது, backend-க்கு கோரிக்கையை முடித்தது, உலாவி பின்னர் வரும் எந்தத் திருப்பிவிடலையும் பின்பற்றி துணை வளங்களை ஏற்றியது. ஒவ்வொரு படிநிலைக்கும் அதன் சொந்தப் பதிவு வரிகள் உள்ளன, அவற்றை வரிசையாகப் படிப்பது தெளிவற்ற 502-ஐ குறிப்பிட்ட கண்டுபிடிப்பாக மாற்றுகிறது.
உங்களுக்குத் தேவையான வேறுபாடு தோல்வியடைந்த upstream இணைப்புக்கும் அணுக முடியாத தனிப்பட்ட பெயருக்கு அனுப்பப்பட்ட உலாவிக்கும் இடையிலானது. முதலாவது ப்ராக்ஸி பிழைப் பதிவில் தோன்றும்; இரண்டாவது ஒருபோதும் வராத கோரிக்கையாகத் தோன்றும், உலாவி தீர்க்க முடியாத host பற்றிப் புகார் கூறும். இரண்டு வெவ்வேறு சிக்கல்கள், இரண்டு வெவ்வேறு கோப்புகள், அவற்றில் ஒன்று மட்டுமே proxy_redirect-உடன் தொடர்புடையது.