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;
}සැබෑ යෝජනා ක්‍රමය, ලිපිනය සහ port භාවිත කරන්න, සහ මෙය යෙදවුමක් ලෙස නොව කොටසක් ලෙස සලකන්න. පිවිසුම් host එකට VPN මාර්ගය, අවසර ලත් යොමු කිරීමේ මාර්ගය සහ එම සේවාවට ක්‍රියාකාරී ආපසු ගමන් රථවාහනයද තබා ගත යුතුය, මන්ද කඩදාසි මත ලිපිනයකට ළඟා වන proxy එකකට තවමත් කර්නලයේ එකඟතාව අවශ්‍ය වේ.
proxy මොඩියුලයේ යොමුව upstream තේරීම ප්‍රතිචාර ශීර්ෂ නැවත ලිවීමෙන් වෙන් කර තබා ගනී, සහ URI අඩංගු proxy_pass අගයක් ගැළපෙන location උපසර්ගය ප්‍රතිස්ථාපනය වන ආකාරය වෙනස් කරන බව සටහන් කරයි. යෙදුම බලාපොරොත්තු වන URL පරීක්ෂා නොකර මාර්ග සංරචක එකතු කිරීම හෝ ඉවත් කිරීම routing අසාර්ථකත්වයක් ලෙස පෙනෙන 404 එකක් නිපදවීමේ විශ්වාසදායක ක්‍රමයකි.
proxy_redirect පෞද්ගලික ලිපිනයක් නිකුත් කරන ප්‍රතිචාර නිවැරදි කරයි
රථවාහන ගලා යාම ආරම්භ වූ පසු, backend එකක් තම පෞද්ගලික ලිපිනය නම් කරන Location ශීර්ෂයක් සමඟ පිළිතුරු දිය හැක. එම ශීර්ෂය අනුගමනය කරන බ්‍රවුසරයක් පොදු පිවිසුම් ලක්ෂ්‍යය හැර දමා එයට විසඳිය නොහැකි දෙයකට ළඟා වීමට උත්සාහ කරයි. හිතාමතා වින්‍යාස කළ ප්‍රතිචාර නැවත ලිවීම පෞද්ගලික URL එක පොදු එක මතට සිතියම් කරයි:
proxy_redirect http://10.40.0.20:8080/ https://app.example.com/;දෙපැත්තම සැබෑ අගයන්ගෙන් ප්‍රතිස්ථාපනය කරන්න. පටු විෂය පථයද තේරුම් ගන්න: ගැළපෙන Location සහ Refresh ශීර්ෂ පෙළ නැවත ලියැවේ, නමුත් HTML, JavaScript හෝ බාගත කළ ගොනු තුළ කාවැද්දූ URL නැවත ලියැවෙන්නේ නැත.
යෙදුමක් සෑම තැනකම නිරපේක්ෂ සබැඳි ගොඩනඟන්නේ නම්, කල් පවත්නා විසඳුම එහිම බාහිර URL වින්‍යාසයයි, proxy එකේ වර්ධනය වන නැවත ලිවීමේ නීති ලැයිස්තුවක් නොවේ. ප්‍රතිදානය නිවැරදි ලෙස පෙනෙන තෙක් නීති එකතු කිරීම කිසිවෙකු පරීක්ෂා නොකළ පළමු පිටුවේම අසාර්ථක වන වින්‍යාසයක් නිපදවයි. යෙදුමේ එක් නිවැරදි සැකසුමක් මුළු එකතුවම ප්‍රතිස්ථාපනය කරයි.
ශීර්ෂ නැවත ලිවීමට නිවැරදි කළ නොහැකි දේ
යාබද ගැටලු කිහිපයක් නැවත යොමු කිරීමේ ගැටලු ලෙස පෙනේ, නමුත් එසේ නොවේ. upstream වෙත යැවෙන Host ශීර්ෂය backend හි අතත්‍ය virtual host එකට ගැළපිය යුතු විය හැක. TLS upstream එකකට නිශ්චිත සේවාදායක නාමයක් සහ සහතික සත්‍යාපනය අවශ්‍ය විය හැක, සහ ප්‍රතිචාර ශීර්ෂයක් නැවත ලිවීම දෙකටම උදව් නොවේ.
කුකී විෂය පථය සහ වසම් ගුණාංග යෙදුමට සහ එහි වින්‍යාසයට අයත් වේ. proxy එකකට දවස පුරා ශීර්ෂ ඉවත් කිරීමට හෝ නැවත ලිවීමට හැකි වුවත් දෙවන ඉල්ලීමේදී අසාර්ථක වන සැසියක් තවමත් නිපදවයි, මන්ද කුකී බ්‍රවුසරය කිසිදා නොගිය host එකකට නිකුත් කර තිබුණි. එම අසාර්ථකත්වය කලින් කලට සිදුවන ලෙස පෙනේ, එබැවින් එය ටිකට් පෝලිමේ මෙතරම් කල් පවතී. කුකීයේ වසම කියවීම සාමාන්‍යයෙන් විමර්ශනය විනාඩියකින් අවසන් කරයි.
සත්‍යාපනය සහ backend තේරීමද අදහස් කළ යෙදුමට සීමා කර තබන්න. පොදු ප්‍රතිලෝම proxy එකක් සේවාදායකයේ VPN හරහා එක් යෙදුමක් පමණක් නිරාවරණය කළ යුතුය, එම host එකට ළඟා විය හැකි සෑම පෞද්ගලික ලිපිනයකටම පොදු ද්වාරයක් වීම වෙනුවට. කථිකයා ඉල්ලන සියල්ල යොමු කරන එකම පොදු location එකක් නිරාවරණය වූ එක් සේවාවක් ඔබේ පෞද්ගලික ජාලයේ සිතියමක් බවට පත් කරයි. upstream එක පැහැදිලිව නම් කර එහිම තබන්න.
ඉල්ලීම ගමන් කරන අනුපිළිවෙලින්ම පරීක්ෂා කරන්න
අනුපිළිවෙලින් කරුණු තුනක් තහවුරු කරන්න: NGINX අදහස් කළ location තෝරා ගත්තේය, backend වෙත ඉල්ලීම සම්පූර්ණ කළේය, සහ බ්‍රවුසරය පසුව එන ඕනෑම නැවත යොමුවක් අනුගමනය කර උප සම්පත් පූරණය කළේය. සෑම පියවරකටම තමන්ගේම ලොග් පේළි ඇත, ඒවා අනුපිළිවෙලින් කියවීම අපැහැදිලි 502 එකක් නිශ්චිත සොයාගැනීමක් බවට පත් කරයි.
ඔබට අවශ්‍ය වෙනස අසාර්ථක upstream සම්බන්ධතාවයක් සහ ළඟා විය නොහැකි පෞද්ගලික නාමයකට යැවූ බ්‍රවුසරයක් අතර ඇත. පළමුවැන්න proxy දෝෂ ලොගයේ දිස්වේ; දෙවැන්න කිසිදා නොඑන ඉල්ලීමක් ලෙස දිස්වේ, බ්‍රවුසරය විසඳිය නොහැකි host එකක් ගැන පැමිණිලි කරයි. වෙනස් ගැටලු දෙකක්, වෙනස් ගොනු දෙකක්, සහ ඉන් එකක් පමණක් proxy_redirect සමඟ සම්බන්ධ වේ.