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 ਨਾਲ ਕੋਈ ਸੰਬੰਧ ਹੈ।