proxy_redirect NGINX ಅನ್ನು ನಿಮ್ಮ VPN ಹೋಸ್ಟ್ಗೆ ಸಂಪರ್ಕಿಸುವುದಿಲ್ಲ
proxy_redirect ಈಗಾಗಲೇ ಬಂದ ಪ್ರತಿಕ್ರಿಯೆಯ ಹೆಡರ್ಗಳನ್ನು ಪುನರ್ಲೇಖನ ಮಾಡುತ್ತದೆ; ಅದು ಎಂದಿಗೂ ಅಪ್ಸ್ಟ್ರೀಮ್ ಆಯ್ಕೆ ಮಾಡುವುದಿಲ್ಲ. proxy_pass, ಬ್ಯಾಕೆಂಡ್ಗೆ ಇರುವ ಮಾರ್ಗ, ನಂತರ ಹೆಡರ್ಗಳನ್ನು ಪರಿಶೀಲಿಸಿ.
ಹೆಸರಿನಲ್ಲಿ redirect ಎಂಬ ಪದವಿದೆ, ಆದ್ದರಿಂದ VPN ಹಿಂದಿನ ಬ್ಯಾಕೆಂಡ್ ತಲುಪಲಾಗದಿದ್ದಾಗ ಅದನ್ನು location ಬ್ಲಾಕ್ಗೆ ಅಂಟಿಸಲಾಗುತ್ತದೆ. ಏನೂ ಬದಲಾಗುವುದಿಲ್ಲ, ಮತ್ತು ಸ್ಪಷ್ಟ ತೀರ್ಮಾನವೆಂದರೆ ಸೂಚನೆ ಮುರಿದಿದೆ ಅಥವಾ ಬೇರೆ ವಾಕ್ಯರಚನೆ ಬೇಕು. ವಾಸ್ತವವಾಗಿ ನಡೆದದ್ದು ಸರಳ ಮತ್ತು ಕಡಿಮೆ ಪ್ರಶಂಸನೀಯ: 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 |
ಆ ಕ್ರಮವೇ ಪೂರ್ಣ ಉತ್ತರ. ಮೊದಲ ಸಾಲು ವಿಫಲವಾದ ಕಾರಣ ಎರಡನೇ ಸಾಲು ಎಂದಿಗೂ ಚಲಿಸದಿದ್ದರೆ, ಎರಡನೇ ಸೂಚನೆ ತಪ್ಪಾಗಿ ಸಂರಚಿಸಲ್ಪಟ್ಟಿಲ್ಲ, ಅದು ಸರಳವಾಗಿ ತಲುಪಲಾಗದ್ದು. ಎರಡನೇ ಸಾಲನ್ನು ಎಷ್ಟೇ ಮತ್ತೆ ಬರೆದರೂ, ಅದು ಸಂಪಾದಿಸಬೇಕಿದ್ದ ಪ್ರತಿಕ್ರಿಯೆ ಹುಟ್ಟುವುದಿಲ್ಲ. ಮೊದಲ ಸಾಲಿನಿಂದ ಹೊರಕ್ಕೆ ನಿರ್ಣಯಿಸಿ, ಗೊಂದಲದ ವರ್ತನೆ ಕಾಣೆಯಾದ ಮಾರ್ಗ ಅಥವಾ ನಿರಾಕರಿಸಿದ ಸಂಪರ್ಕಕ್ಕೆ ಇಳಿಯುತ್ತದೆ.
ಅಪ್ಸ್ಟ್ರೀಮ್ ಆಯ್ಕೆ proxy_pass ನ ಕೆಲಸ
NGINX ಸಾರ್ವಜನಿಕ ಪ್ರವೇಶ ಹೋಸ್ಟ್ನಲ್ಲಿ ಚಲಿಸುತ್ತದೆ ಮತ್ತು ತನ್ನ VPN ಮೂಲಕ 10.40.0.20:8080 ನಲ್ಲಿನ ಅಪ್ಲಿಕೇಶನ್ ತಲುಪುತ್ತದೆ ಎಂದು ಭಾವಿಸಿ. ಆ ಅಪ್ಲಿಕೇಶನ್ ಆಯ್ಕೆ ಮಾಡುವ ತುಣುಕು ಇರುವ server ಬ್ಲಾಕ್ ಒಳಗೆ ಹೀಗೆ ಕಾಣುತ್ತದೆ:
location / {
proxy_pass http://10.40.0.20:8080;
}ನಿಜವಾದ ಸ್ಕೀಮ್, ವಿಳಾಸ ಮತ್ತು ಪೋರ್ಟ್ ಬಳಸಿ, ಮತ್ತು ಇದನ್ನು ನಿಯೋಜನೆ ಅಲ್ಲದೆ ತುಣುಕು ಎಂದು ಪರಿಗಣಿಸಿ. ಪ್ರವೇಶ ಹೋಸ್ಟ್ VPN ಮಾರ್ಗ, ಅನುಮತಿಸಿದ ಮುಂದಕ್ಕೆ ಕಳುಹಿಸುವ ದಾರಿ ಮತ್ತು ಆ ಸೇವೆಗೆ ಕೆಲಸ ಮಾಡುವ ಹಿಂತಿರುಗುವ ಸಂಚಾರವನ್ನೂ ಹಿಡಿದಿಟ್ಟುಕೊಳ್ಳಬೇಕು, ಏಕೆಂದರೆ ಕಾಗದದ ಮೇಲೆ ವಿಳಾಸ ತಲುಪುವ ಪ್ರಾಕ್ಸಿಗೂ ಕರ್ನೆಲ್ನ ಒಪ್ಪಿಗೆ ಬೇಕು.
proxy ಮಾಡ್ಯೂಲ್ನ ಉಲ್ಲೇಖವು ಅಪ್ಸ್ಟ್ರೀಮ್ ಆಯ್ಕೆಯನ್ನು ಪ್ರತಿಕ್ರಿಯೆ-ಹೆಡರ್ ಪುನರ್ಲೇಖನದಿಂದ ಪ್ರತ್ಯೇಕವಾಗಿ ಇಡುತ್ತದೆ, ಮತ್ತು URI ಹೊಂದಿರುವ proxy_pass ಮೌಲ್ಯವು ಹೊಂದಿಕೆಯಾಗುವ location ಪೂರ್ವಪ್ರತ್ಯಯವನ್ನು ಹೇಗೆ ಬದಲಾಯಿಸಲಾಗುತ್ತದೆ ಎಂಬುದನ್ನು ಬದಲಿಸುತ್ತದೆ ಎಂದು ಗಮನಿಸುತ್ತದೆ. ಅಪ್ಲಿಕೇಶನ್ ನಿರೀಕ್ಷಿಸುವ URL ಪರಿಶೀಲಿಸದೆ ಮಾರ್ಗ ಘಟಕಗಳನ್ನು ಸೇರಿಸುವುದು ಅಥವಾ ತೆಗೆಯುವುದು ರೂಟಿಂಗ್ ವೈಫಲ್ಯದಂತೆ ಕಾಣುವ 404 ಉತ್ಪಾದಿಸುವ ನಂಬಿಕಾರ್ಹ ದಾರಿ.
proxy_redirect ಖಾಸಗಿ ವಿಳಾಸ ಸೋರಿಸುವ ಪ್ರತಿಕ್ರಿಯೆಗಳನ್ನು ಸರಿಪಡಿಸುತ್ತದೆ
ಸಂಚಾರ ಹರಿಯಲು ಪ್ರಾರಂಭಿಸಿದಾಗ, ಬ್ಯಾಕೆಂಡ್ ತನ್ನ ಖಾಸಗಿ ವಿಳಾಸವನ್ನು ಹೆಸರಿಸುವ Location ಹೆಡರ್ನೊಂದಿಗೆ ಉತ್ತರಿಸಬಹುದು. ಆ ಹೆಡರ್ ಅನ್ನು ಅನುಸರಿಸುವ ಬ್ರೌಸರ್ ಸಾರ್ವಜನಿಕ ಪ್ರವೇಶ ಬಿಂದುವನ್ನು ಬಿಟ್ಟು, ಅದು ಪರಿಹರಿಸಲಾಗದ ಯಾವುದನ್ನೋ ತಲುಪಲು ಪ್ರಯತ್ನಿಸುತ್ತದೆ. ಉದ್ದೇಶಪೂರ್ವಕವಾಗಿ ಸಂರಚಿಸಿದ ಪ್ರತಿಕ್ರಿಯೆ ಪುನರ್ಲೇಖನವು ಖಾಸಗಿ URL ಅನ್ನು ಸಾರ್ವಜನಿಕದ ಮೇಲೆ ನಕ್ಷೆ ಮಾಡುತ್ತದೆ:
proxy_redirect http://10.40.0.20:8080/ https://app.example.com/;ಎರಡೂ ಬದಿಗಳನ್ನು ನಿಜವಾದ ಮೌಲ್ಯಗಳಿಂದ ಬದಲಾಯಿಸಿ. ಸಂಕುಚಿತ ವ್ಯಾಪ್ತಿಯನ್ನೂ ಅರ್ಥಮಾಡಿಕೊಳ್ಳಿ: ಹೊಂದಿಕೆಯಾಗುವ Location ಮತ್ತು Refresh ಹೆಡರ್ಗಳ ಪಠ್ಯವು ಪುನರ್ಲೇಖನಗೊಳ್ಳುತ್ತದೆ, ಆದರೆ HTML, JavaScript ಅಥವಾ ಡೌನ್ಲೋಡ್ ಮಾಡಿದ ಫೈಲ್ಗಳಲ್ಲಿ ಹುದುಗಿಸಿದ URL ಗಳಲ್ಲ.
ಅಪ್ಲಿಕೇಶನ್ ಎಲ್ಲೆಡೆ ಸಂಪೂರ್ಣ ಕೊಂಡಿಗಳನ್ನು ನಿರ್ಮಿಸಿದರೆ, ಶಾಶ್ವತ ಪರಿಹಾರ ಅದರ ಸ್ವಂತ ಬಾಹ್ಯ-URL ಸಂರಚನೆ, ಪ್ರಾಕ್ಸಿಯಲ್ಲಿ ಬೆಳೆಯುತ್ತಿರುವ ಪುನರ್ಲೇಖನ ನಿಯಮಗಳ ಪಟ್ಟಿಯಲ್ಲ. ಔಟ್ಪುಟ್ ಸರಿಯಾಗಿ ಕಾಣುವವರೆಗೆ ನಿಯಮ ಸೇರಿಸುವುದು ಯಾರೂ ಪರೀಕ್ಷಿಸದ ಮೊದಲ ಪುಟದಲ್ಲಿ ವಿಫಲವಾಗುವ ಸಂರಚನೆಯನ್ನು ಉಂಟುಮಾಡುತ್ತದೆ. ಅಪ್ಲಿಕೇಶನ್ನ ಒಂದು ಸರಿಯಾದ ಸೆಟ್ಟಿಂಗ್ ಇಡೀ ಸಂಗ್ರಹವನ್ನು ಬದಲಾಯಿಸುತ್ತದೆ.
ಹೆಡರ್ ಪುನರ್ಲೇಖನ ಸರಿಪಡಿಸಲಾಗದ್ದು
ಹಲವು ಪಕ್ಕದ ಸಮಸ್ಯೆಗಳು ಮರುನಿರ್ದೇಶನ ಸಮಸ್ಯೆಗಳಂತೆ ಕಾಣುತ್ತವೆ, ಆದರೆ ಅಲ್ಲ. ಅಪ್ಸ್ಟ್ರೀಮ್ಗೆ ಕಳುಹಿಸುವ Host ಹೆಡರ್ ಬ್ಯಾಕೆಂಡ್ನ ವರ್ಚುವಲ್ ಹೋಸ್ಟ್ಗೆ ಹೊಂದಿಕೆಯಾಗಬೇಕಾಗಬಹುದು. TLS ಅಪ್ಸ್ಟ್ರೀಮ್ಗೆ ನಿರ್ದಿಷ್ಟ ಸರ್ವರ್ ಹೆಸರು ಜೊತೆಗೆ ಪ್ರಮಾಣಪತ್ರ ಪರಿಶೀಲನೆ ಬೇಕಾಗಬಹುದು, ಮತ್ತು ಪ್ರತಿಕ್ರಿಯೆ ಹೆಡರ್ ಪುನರ್ಲೇಖನ ಎರಡಕ್ಕೂ ಸಹಾಯ ಮಾಡುವುದಿಲ್ಲ.
ಕುಕಿ ವ್ಯಾಪ್ತಿ ಮತ್ತು ಡೊಮೇನ್ ಗುಣಲಕ್ಷಣಗಳು ಅಪ್ಲಿಕೇಶನ್ ಮತ್ತು ಅದರ ಸಂರಚನೆಗೆ ಸೇರಿವೆ. ಪ್ರಾಕ್ಸಿ ದಿನವಿಡೀ ಹೆಡರ್ಗಳನ್ನು ಬಿಸಾಡಬಹುದು ಅಥವಾ ಪುನರ್ಲೇಖನ ಮಾಡಬಹುದು, ಆದರೂ ಎರಡನೇ ವಿನಂತಿಯಲ್ಲಿ ವಿಫಲವಾಗುವ ಅಧಿವೇಶನವನ್ನು ಉಂಟುಮಾಡುತ್ತದೆ, ಏಕೆಂದರೆ ಕುಕಿಯನ್ನು ಬ್ರೌಸರ್ ಎಂದೂ ಭೇಟಿ ನೀಡದ ಹೋಸ್ಟ್ಗೆ ನೀಡಲಾಗಿತ್ತು. ಆ ವೈಫಲ್ಯ ಮಧ್ಯೆ ಮಧ್ಯೆ ಸಂಭವಿಸುವಂತೆ ಕಾಣುತ್ತದೆ, ಆದ್ದರಿಂದ ಟಿಕೆಟ್ ಸರದಿಯಲ್ಲಿ ಅಷ್ಟು ಕಾಲ ಉಳಿಯುತ್ತದೆ. ಕುಕಿಯ ಡೊಮೇನ್ ಓದುವುದು ಸಾಮಾನ್ಯವಾಗಿ ಒಂದು ನಿಮಿಷದಲ್ಲಿ ತನಿಖೆಯನ್ನು ಮುಗಿಸುತ್ತದೆ.
ದೃಢೀಕರಣ ಮತ್ತು ಬ್ಯಾಕೆಂಡ್ ಆಯ್ಕೆಯನ್ನೂ ಉದ್ದೇಶಿತ ಅಪ್ಲಿಕೇಶನ್ಗೆ ಸೀಮಿತಗೊಳಿಸಿ. ಸಾರ್ವಜನಿಕ ರಿವರ್ಸ್ ಪ್ರಾಕ್ಸಿ ಸರ್ವರ್ನ VPN ಮೂಲಕ ಒಂದು ಅಪ್ಲಿಕೇಶನ್ ಬಹಿರಂಗಪಡಿಸಬೇಕೇ ಹೊರತು ಆ ಹೋಸ್ಟ್ ತಲುಪಬಲ್ಲ ಪ್ರತಿ ಖಾಸಗಿ ವಿಳಾಸಕ್ಕೂ ಸಾಮಾನ್ಯ ಗೇಟ್ವೇ ಆಗುವುದಲ್ಲ. ಕರೆ ಮಾಡುವವರು ಕೇಳಿದ್ದೆಲ್ಲವನ್ನೂ ರವಾನಿಸುವ ಒಂದೇ ಸಾಮಾನ್ಯ location ಒಂದು ಬಹಿರಂಗ ಸೇವೆಯನ್ನು ನಿಮ್ಮ ಖಾಸಗಿ ಜಾಲದ ನಕ್ಷೆಯಾಗಿ ಬದಲಿಸುತ್ತದೆ. ಅಪ್ಸ್ಟ್ರೀಮ್ ಅನ್ನು ಸ್ಪಷ್ಟವಾಗಿ ಹೆಸರಿಸಿ ಮತ್ತು ಅಲ್ಲಿಯೇ ಇಡಿ.
ವಿನಂತಿ ಸಾಗುವ ಕ್ರಮದಲ್ಲೇ ಪರೀಕ್ಷಿಸಿ
ಕ್ರಮವಾಗಿ ಮೂರು ವಿಷಯಗಳನ್ನು ಖಚಿತಪಡಿಸಿ: NGINX ಉದ್ದೇಶಿತ location ಆಯ್ಕೆ ಮಾಡಿತು, ಬ್ಯಾಕೆಂಡ್ಗೆ ವಿನಂತಿ ಪೂರ್ಣಗೊಳಿಸಿತು, ಮತ್ತು ಬ್ರೌಸರ್ ನಂತರದ ಯಾವುದೇ ಮರುನಿರ್ದೇಶನವನ್ನು ಅನುಸರಿಸಿ ಉಪಸಂಪನ್ಮೂಲಗಳನ್ನು ಲೋಡ್ ಮಾಡಿತು. ಪ್ರತಿ ಹಂತಕ್ಕೂ ತನ್ನದೇ ಲಾಗ್ ಸಾಲುಗಳಿವೆ, ಮತ್ತು ಅವನ್ನು ಕ್ರಮದಲ್ಲಿ ಓದುವುದು ಅಸ್ಪಷ್ಟ 502 ಅನ್ನು ನಿರ್ದಿಷ್ಟ ಸಂಶೋಧನೆಯಾಗಿ ಬದಲಿಸುತ್ತದೆ.
ನಿಮಗೆ ಬೇಕಾದ ವ್ಯತ್ಯಾಸ ವಿಫಲ ಅಪ್ಸ್ಟ್ರೀಮ್ ಸಂಪರ್ಕ ಮತ್ತು ತಲುಪಲಾಗದ ಖಾಸಗಿ ಹೆಸರಿಗೆ ಕಳುಹಿಸಲಾದ ಬ್ರೌಸರ್ ನಡುವಿನದು. ಮೊದಲನೆಯದು ಪ್ರಾಕ್ಸಿ ದೋಷ ಲಾಗ್ನಲ್ಲಿ ಕಾಣುತ್ತದೆ; ಎರಡನೆಯದು ಎಂದಿಗೂ ಬಾರದ ವಿನಂತಿಯಂತೆ ಕಾಣುತ್ತದೆ, ಬ್ರೌಸರ್ ಪರಿಹರಿಸಲಾಗದ ಹೋಸ್ಟ್ ಬಗ್ಗೆ ದೂರುತ್ತದೆ. ಎರಡು ಬೇರೆ ಸಮಸ್ಯೆಗಳು, ಎರಡು ಬೇರೆ ಫೈಲ್ಗಳು, ಮತ್ತು ಅವುಗಳಲ್ಲಿ ಒಂದು ಮಾತ್ರ proxy_redirect ಗೆ ಸಂಬಂಧಿಸಿದೆ.