VPN ਮੁੜ ਜੁੜਨ ਤੋਂ ਬਾਅਦ ਪ੍ਰੌਕਸੀ ਅਜੇ ਵੀ ਪੁਰਾਣੇ ਟਨਲ ਪਤੇ 'ਤੇ ਹੈ?
ਮੁੜ ਜੁੜਨਾ ਤੁਹਾਡੇ ਫਾਰਵਰਡਰ ਨੂੰ ਉਸ ਪਤੇ ਨਾਲ ਬੰਨ੍ਹਿਆ ਛੱਡ ਸਕਦਾ ਹੈ ਜੋ ਟਨਲ ਕੋਲ ਹੁਣ ਨਹੀਂ ਹੈ। ਚਾਰ ਕ੍ਰਮਬੱਧ ਜਾਂਚਾਂ, ਇੱਕ ਨੰਬਰੀ ਹਸਤਾਂਤਰਣ ਅਤੇ ਇੱਕ ਅਸਲੀ ਟੈਸਟ ਬੇਨਤੀ।
VPN ਕਲਾਇੰਟ ਨੂੰ ਮੁੜ ਚਾਲੂ ਕਰਨਾ ਸਿਰਫ਼ ਇਹ ਸਾਬਤ ਕਰਦਾ ਹੈ ਕਿ ਟਨਲ ਵਾਪਸ ਆ ਗਿਆ ਹੈ। ਇਹ ਉਸ ਪ੍ਰੌਕਸੀ ਬਾਰੇ ਕੁਝ ਨਹੀਂ ਕਹਿੰਦਾ ਜਿਸ ਨੂੰ ਇਸ ਵਿੱਚੋਂ ਬਾਹਰ ਜਾਣ ਦਾ ਹੁਕਮ ਦਿੱਤਾ ਗਿਆ ਸੀ। Squid, tinyproxy ਅਤੇ ਹੋਰ ਜ਼ਿਆਦਾਤਰ ਫਾਰਵਰਡਰ ਸ਼ੁਰੂ ਵੇਲੇ ਲੱਭਿਆ ਸਥਾਨਕ ਸਰੋਤ ਪਤਾ ਉਦੋਂ ਤੱਕ ਰੱਖਦੇ ਹਨ ਜਦੋਂ ਤੱਕ ਕੋਈ ਚੀਜ਼ ਉਨ੍ਹਾਂ ਨੂੰ ਮੁੜ ਲੋਡ ਕਰਨ ਲਈ ਮਜਬੂਰ ਨਹੀਂ ਕਰਦੀ। ਜਦੋਂ ਮੁੜ ਜੁੜਨਾ ਨਵਾਂ ਟਨਲ ਪਤਾ ਦਿੰਦਾ ਹੈ, ਫਾਰਵਰਡਰ ਜਾਂ ਤਾਂ ਹਰ ਬਾਹਰ ਜਾਣ ਵਾਲੇ ਕਨੈਕਸ਼ਨ 'ਤੇ ਫੇਲ੍ਹ ਹੋ ਜਾਂਦਾ ਹੈ, ਜਾਂ ਤੁਹਾਡੇ ਆਮ ਰਸਤੇ ਰਾਹੀਂ ਬਾਹਰ ਜਾਣ ਲੱਗਦਾ ਹੈ।
ਦੂਜੀ ਫੇਲ੍ਹਤਾ ਹੀ ਖ਼ਤਰਨਾਕ ਹੈ: ਟਨਲ ਚਾਲੂ ਹੈ, ਪੰਨੇ ਲੋਡ ਹੋ ਰਹੇ ਹਨ, ਅਤੇ ਸਿਰਫ਼ ਬਾਹਰ ਜਾਣ ਵਾਲਾ ਪਤਾ ਗਲਤ ਹੈ।
ਟਨਲ ਨਾਲ ਨਹੀਂ, ਲਿਸਨਰ ਨਾਲ ਸ਼ੁਰੂ ਕਰੋ
ਖੇਡ ਵਿੱਚ ਤਿੰਨ ਪਤੇ ਹਨ, ਅਤੇ ਮੁੜ ਜੁੜਨਾ ਉਨ੍ਹਾਂ ਵਿੱਚੋਂ ਸਿਰਫ਼ ਕੁਝ ਨੂੰ ਹਿਲਾਉਂਦਾ ਹੈ। ਲਿਸਨਰ ਉਹ ਹੈ ਜਿੱਥੇ ਤੁਹਾਡਾ ਬ੍ਰਾਊਜ਼ਰ ਇਸ਼ਾਰਾ ਕਰਦਾ ਹੈ, ਆਮ ਤੌਰ 'ਤੇ 127.0.0.1 ਜਾਂ LAN ਪਤਾ, ਅਤੇ ਟਨਲ ਬਦਲਣ ਦੀ ਉਸਨੂੰ ਪਰਵਾਹ ਨਹੀਂ। ਬਾਹਰ ਜਾਣ ਵਾਲਾ ਸਥਾਨਕ ਸਰੋਤ ਉਹ ਹੈ ਜੋ ਫਾਰਵਰਡਰ ਅਗਲੇ ਹੌਪ ਨੂੰ ਡਾਇਲ ਕਰਦੇ ਸਮੇਂ ਕਰਨਲ ਨੂੰ ਵਰਤਣ ਲਈ ਕਹਿੰਦਾ ਹੈ, ਅਤੇ ਇਹ ਟਨਲ ਯੰਤਰ ਨਾਲ ਬੱਝਿਆ ਹੁੰਦਾ ਹੈ। ਜਨਤਕ ਨਿਕਾਸ ਉਹ ਹੈ ਜੋ ਵੈੱਬ ਸਰਵਰ ਦਰਜ ਕਰਦਾ ਹੈ, ਅਤੇ ਇਹ ਕੁਝ ਹੌਪ ਦੂਰ ਦਾ ਅਨੁਵਾਦਿਤ ਪਤਾ ਹੋ ਸਕਦਾ ਹੈ।
ਜਨਤਕ IP ਦੀ ਖੋਜ ਸਿਰਫ਼ ਆਖਰੀ ਸਵਾਲ ਦਾ ਜਵਾਬ ਦਿੰਦੀ ਹੈ। ਇੱਕ ਜਨਤਕ ਨਿਕਾਸ ਕਈ ਅੰਦਰੂਨੀ ਸਰੋਤ ਲੁਕਾ ਸਕਦਾ ਹੈ, ਇਸ ਲਈ ਇਹ ਨਹੀਂ ਦੱਸ ਸਕਦੀ ਕਿ ਫਾਰਵਰਡਰ ਨੂੰ ਕਿਹੜੇ ਸਥਾਨਕ ਪਤੇ ਨਾਲ ਬੱਝਣਾ ਚਾਹੀਦਾ ਹੈ। ਪਤਾ ਉਸ ਤੋਂ ਪੜ੍ਹੋ ਜਿਸ ਕੋਲ ਕਨੈਕਸ਼ਨ ਹੈ: ਕਲਾਇੰਟ ਦਾ ਸਥਿਤੀ ਆਉਟਪੁੱਟ, ਇੰਟਰਫੇਸ ਖੁਦ, ਜਾਂ ਉਹ ਨੇਮਸਪੇਸ ਜਿੱਥੇ ਟਨਲ ਰਹਿੰਦਾ ਹੈ। ਟਨਲ ਵਰਗਾ ਨਾਮ ਵਾਲਾ ਪਹਿਲਾ ਇੰਟਰਫੇਸ ਫੜਨਾ ਦੂਜੀ ਪ੍ਰੋਫ਼ਾਈਲ ਹੁੰਦਿਆਂ ਹੀ ਗਲਤ ਜਵਾਬ ਦਿੰਦਾ ਹੈ।
ਕੰਟੇਨਰ ਅਤੇ ਨੇਮਸਪੇਸ ਬਣਤਰਾਂ ਇਸ ਧਾਰਨਾ ਨੂੰ ਚੁੱਪਚਾਪ ਤੋੜਦੀਆਂ ਹਨ। ਇੱਕ ਨੈੱਟਵਰਕ ਨੇਮਸਪੇਸ ਵਿੱਚ ਫਾਰਵਰਡਰ ਦੂਜੇ ਵਿੱਚ ਮੌਜੂਦ ਟਨਲ ਨਾਲ ਨਹੀਂ ਬੱਝ ਸਕਦਾ, ਅਤੇ ਕਨਫਿਗਰੇਸ਼ਨ ਸੋਧ ਦੀ ਕੋਈ ਵੀ ਮਾਤਰਾ ਇਹ ਠੀਕ ਨਹੀਂ ਕਰਦੀ।
ਕੁਝ ਵੀ ਸੋਧਣ ਤੋਂ ਪਹਿਲਾਂ ਚਾਰ ਜਾਂਚਾਂ
ਇਹ ਕ੍ਰਮ ਵਿੱਚ ਕਰੋ। ਪਹਿਲੀ ਫੇਲ੍ਹ ਹੋਣ ਵਾਲੀ ਜਾਂਚ ਹੀ ਰੁਕਣ ਦੀ ਥਾਂ ਹੈ, ਕਿਉਂਕਿ ਅੱਗੇ ਵਾਲੀਆਂ ਪਿਛਲੀਆਂ ਨੂੰ ਸਹੀ ਮੰਨਦੀਆਂ ਹਨ।
- ਪੱਕਾ ਕਰੋ ਕਿ ਵਰਤਿਆ ਜਾ ਰਿਹਾ ਟਨਲ ਉਹ ਪ੍ਰੋਫ਼ਾਈਲ ਹੈ ਜਿਸ ਦੁਆਲੇ ਪ੍ਰੌਕਸੀ ਬਣੀ ਸੀ, ਨਾ ਕਿ ਆਪਣੇ ਆਪ ਜੁੜੀ ਦੂਜੀ ਪ੍ਰੋਫ਼ਾਈਲ।
- ਉਸ ਯੰਤਰ 'ਤੇ ਮੌਜੂਦਾ ਪਤਾ ਪ੍ਰਿੰਟ ਕਰੋ ਅਤੇ ਚੱਲ ਰਹੀ ਕਨਫਿਗਰੇਸ਼ਨ ਦੇ ਪਤੇ ਨਾਲ ਤੁਲਨਾ ਕਰੋ।
- ਡਿਸਕ 'ਤੇ ਪਈ ਫਾਈਲ ਦਾ ਦਾਅਵਾ ਨਹੀਂ, ਫਾਰਵਰਡਰ ਨੂੰ ਪੁੱਛੋ ਕਿ ਉਸਨੇ ਕਿਹੜਾ ਸਰੋਤ ਲੱਭਿਆ।
- ਪੱਕਾ ਕਰੋ ਕਿ ਫਾਰਵਰਡਰ ਦਾ ਟ੍ਰੈਫਿਕ ਸੱਚਮੁੱਚ ਤੁਹਾਡੇ ਉਮੀਦ ਕੀਤੇ ਰਾਊਟਿੰਗ ਅਤੇ ਫਾਇਰਵਾਲ ਨੀਤੀ ਦੇ ਅਧੀਨ ਹੈ।
ਯੰਤਰ ਦਾ ਪਤਾ ਸੌਖਾ ਹੈ: ip -4 addr show dev tun0 ਮੌਜੂਦਾ ਪ੍ਰਿੰਟ ਕਰਦਾ ਹੈ, ਅਤੇ ip -4 route get 1.1.1.1 ਦਿਖਾਉਂਦਾ ਹੈ ਕਿ ਉਸ ਮੰਜ਼ਿਲ ਲਈ ਕਰਨਲ ਕਿਹੜਾ ਇੰਟਰਫੇਸ ਚੁਣੇਗਾ। ਸਹੀ ਪਤੇ ਨਾਲ ਬੱਝਣ ਵਾਲਾ ਫਾਰਵਰਡਰ ਪਤਾ ਗਾਇਬ ਹੋਣ 'ਤੇ ਉੱਚੀ ਆਵਾਜ਼ ਵਿੱਚ ਫੇਲ੍ਹ ਹੁੰਦਾ ਹੈ। ਯੰਤਰ ਨਾਲ ਬੱਝਣ ਵਾਲਾ, ਜਾਂ ਡਿਫ਼ਾਲਟ ਸਰੋਤ 'ਤੇ ਵਾਪਸ ਜਾਣ ਵਾਲਾ ਫਾਰਵਰਡਰ ਕੰਮ ਕਰਦਾ ਰਹਿੰਦਾ ਹੈ ਅਤੇ ਲੀਕ ਕਰਦਾ ਹੈ, ਅਤੇ ਇਹੀ ਚੁੱਪ ਨਤੀਜਾ ਹੈ।
ਦਸਤਾਵੇਜ਼ ਨੂੰ ਉਸ ਰਿਲੀਜ਼ ਨਾਲ ਮਿਲਾਓ ਜੋ ਤੁਸੀਂ ਚਲਾਉਂਦੇ ਹੋ, ਖੋਜ ਦੇ ਸਭ ਤੋਂ ਉੱਪਰਲੇ ਨਤੀਜੇ ਨਾਲ ਨਹੀਂ। Squid ਦੀ ਬਾਹਰ ਜਾਣ ਵਾਲੇ ਪਤੇ ਦੀ ਹਦਾਇਤ v7 ਅਤੇ ਇਸ ਤੋਂ ਪਹਿਲਾਂ ਲਈ ਦਸਤਾਵੇਜ਼ੀ ਹੈ, ਅਤੇ v8 ਦਸਤਾਵੇਜ਼ ਸਪਸ਼ਟ ਕਹਿੰਦਾ ਹੈ ਕਿ ਉੱਥੇ ਇਹ ਹਦਾਇਤ ਉਪਲਬਧ ਨਹੀਂ, ਇਸ ਲਈ ਇਸ ਦੁਆਲੇ ਬਣੀ ਸਕ੍ਰਿਪਟ ਉਹ ਸੀਮਾ ਪਾਰ ਨਹੀਂ ਕਰਦੀ (Squid tcp_outgoing_address ਸੰਦਰਭ ਵੇਖੋ)। ਕੁਝ ਵੀ ਮੁੜ ਲੋਡ ਕਰਨ ਤੋਂ ਪਹਿਲਾਂ ਉਤਪਾਦ ਦੇ ਆਪਣੇ ਪਾਰਸਰ ਨਾਲ ਜਾਂਚੋ: squid -k parse ਗਲਤੀਆਂ ਦੀ ਰਿਪੋਰਟ ਕਰਦਾ ਹੈ ਅਤੇ ਚੱਲ ਰਹੀ ਪ੍ਰਕਿਰਿਆ ਨੂੰ ਛੂਹੇ ਬਿਨਾਂ ਬਾਹਰ ਨਿਕਲਦਾ ਹੈ।
ਹਰ ਟਨਲ ਨੂੰ ਨੰਬਰ ਦਿਓ ਅਤੇ ਪੁਰਾਣੀਆਂ ਅਦਲਾ-ਬਦਲੀਆਂ ਸੁੱਟ ਦਿਓ
ਮੁੜ ਜੁੜਨਾ ਇੱਕ ਹਸਤਾਂਤਰਣ ਹੈ, ਅਤੇ ਹਸਤਾਂਤਰਣ ਨੂੰ ਕ੍ਰਮ ਚਾਹੀਦਾ ਹੈ। ਹਰ ਦੇਖੇ ਗਏ ਕਨੈਕਸ਼ਨ 'ਤੇ ਹਰ ਸਫਲ ਸਥਾਪਨਾ 'ਤੇ ਵਧਣ ਵਾਲਾ ਕਾਊਂਟਰ ਜਾਂ ਸਮਾਂ-ਛਾਪ ਟੈਗ ਲਾਓ, ਫਿਰ ਉਹ ਟੈਗ ਉਮੀਦਵਾਰ ਕਨਫਿਗਰੇਸ਼ਨ ਅੰਦਰ ਲੈ ਜਾਓ। ਜਦੋਂ ਉਮੀਦਵਾਰ 'ਤੇ ਟੈਗ ਮੌਜੂਦਾ ਨਾਲੋਂ ਪੁਰਾਣਾ ਹੋਵੇ, ਲਾਗੂ ਕਰਨ ਦੀ ਥਾਂ ਉਮੀਦਵਾਰ ਸੁੱਟ ਦਿਓ, ਕਿਉਂਕਿ ਪਿਛਲੇ ਟਨਲ ਲਈ ਲਿਖੀ ਹੌਲੀ ਅੱਪਡੇਟ ਨਹੀਂ ਤਾਂ ਮੌਜੂਦਾ ਦੀਆਂ ਸੈਟਿੰਗਾਂ ਉੱਤੇ ਲਿਖ ਦੇਵੇਗੀ। ਘਟਨਾਵਾਂ ਦੀਆਂ ਲਹਿਰਾਂ ਨੂੰ ਜੋੜੋ ਤਾਂ ਜੋ ਡੋਲਦਾ ਲਿੰਕ ਪੰਦਰਾਂ ਦੀ ਥਾਂ ਇੱਕ ਬਦਲਾਅ ਦੇਵੇ।
ਕੰਮ ਨੂੰ ਚਾਰ ਕਦਮਾਂ ਵਿੱਚ ਰੱਖੋ: ਪੁਰਾਣੀ ਨਿਕਾਸ ਸਥਿਤੀ ਅਵੈਧ ਕਰੋ, ਕਨੈਕਸ਼ਨ ਦੇ ਮਾਲਕ ਦੀ ਪੂਰਨਤਾ ਰਿਪੋਰਟ ਦੀ ਉਡੀਕ ਕਰੋ, ਸਿਰਫ਼ ਪ੍ਰਬੰਧਿਤ ਟੁਕੜਾ ਬਣਾਓ, ਫਿਰ ਸੇਵਾ ਪ੍ਰਬੰਧਕ ਰਾਹੀਂ ਜਾਂਚੋ ਅਤੇ ਸਰਗਰਮ ਕਰੋ। ਦੋ ਪਤਾ ਮੁੱਲਾਂ ਤੋਂ ਪੂਰੀ ਫਾਈਲ ਮੁੜ ਬਣਾਉਣਾ ਹੀ ਲਿਸਨਰ ਪਾਬੰਦੀਆਂ, ਪ੍ਰਮਾਣਿਕਤਾ ਅਤੇ ਮੰਜ਼ਿਲ ਨੀਤੀ ਚੁੱਪਚਾਪ ਗਾਇਬ ਹੋਣ ਦਾ ਰਾਹ ਹੈ। ਜਾਣ-ਬੁੱਝ ਕੇ ਰੋਕਣ ਦਾ ਵੀ ਸਤਿਕਾਰ ਕਰੋ। ਵਰਤੋਂਕਾਰ ਵੱਲੋਂ ਬੰਦ ਕੀਤੇ ਟਨਲ 'ਤੇ ਡਾਇਲ ਕਰਦੇ ਰਹਿਣ ਵਾਲਾ ਸਹਾਇਕ ਬੱਗ ਹੈ, ਲਚਕਤਾ ਨਹੀਂ।
ਖੁੱਲ੍ਹੇ ਸਾਕਟ ਨਵੇਂ ਪਤੇ ਦਾ ਪਿੱਛਾ ਨਹੀਂ ਕਰਨਗੇ
ਫਾਰਵਰਡਰ ਨੂੰ ਮੁੜ ਸੰਰਚਿਤ ਕਰਨਾ ਪਹਿਲਾਂ ਹੀ ਸਥਾਪਿਤ ਕਨੈਕਸ਼ਨਾਂ ਬਾਰੇ ਕੁਝ ਨਹੀਂ ਕਹਿੰਦਾ। ਉਹ ਖਾਲੀ ਹੋਣਗੇ ਜਾਂ ਮਰਨਗੇ ਇਹ ਉਤਪਾਦ 'ਤੇ ਨਿਰਭਰ ਹੈ, ਇਸ ਲਈ ਮੰਨਣ ਦੀ ਥਾਂ ਵਿਵਹਾਰ ਦੇਖੋ।
ਬਦਲੀ ਤੋਂ ਪਹਿਲਾਂ ਖੋਲ੍ਹੇ ਸਾਕਟ ਰਾਹੀਂ ਦਿੱਤੀ ਬੇਨਤੀ ਨਵੀਂ ਕਨਫਿਗਰੇਸ਼ਨ ਸਹੀ ਹੋਣ 'ਤੇ ਵੀ ਪੁਰਾਣੇ ਰਸਤੇ ਰਾਹੀਂ ਬਾਹਰ ਜਾਂਦੀ ਹੈ। ਜੇ ਇਹ ਮਹੱਤਵਪੂਰਨ ਹੈ ਤਾਂ ਸਪਸ਼ਟ ਫ਼ੈਸਲਾ ਕਰੋ: ਥੋੜ੍ਹਾ ਖਾਲੀ ਹੋਣ ਦਾ ਸਮਾਂ ਦਿਓ ਅਤੇ ਨਵਾਂ ਕੰਮ ਲੈਣਾ ਬੰਦ ਕਰੋ, ਜਾਂ ਪੁਰਾਣੇ ਸਾਕਟ ਬੰਦ ਕਰੋ ਅਤੇ ਗਲਤੀਆਂ ਸਵੀਕਾਰ ਕਰੋ। ਫਿਰ ਨਵੇਂ ਕਨੈਕਸ਼ਨ ਨਾਲ ਟੈਸਟ ਕਰੋ ਅਤੇ ਉਹ ਨਤੀਜਾ ਖਾਲੀ ਹੋਣ ਦੀ ਜਾਂਚ ਤੋਂ ਵੱਖ ਰੱਖੋ। ਸਰੋਤ ਨਾਲ ਬੱਝਣਾ ਵੀ ਸੁਰੱਖਿਆ ਸੀਮਾ ਨਹੀਂ। ਜਦੋਂ ਟ੍ਰੈਫਿਕ ਨੂੰ ਕਦੇ ਵੀ ਆਮ ਰਸਤਾ ਛੂਹਣਾ ਨਹੀਂ ਚਾਹੀਦਾ, ਤਾਂ ਇਹ ਨਿਸ਼ਾਨਾਂ ਅਤੇ ਫਾਇਰਵਾਲ ਨਿਯਮਾਂ ਨਾਲ, DNS ਅਤੇ IPv6 ਸਮੇਤ ਲਾਗੂ ਕਰੋ, ਤਾਂ ਜੋ ਫੇਲ੍ਹ ਮੁੜ ਲੋਡ ਪ੍ਰੌਕਸੀ ਨੂੰ ਖੁੱਲ੍ਹਾ ਛੱਡਣ ਦੀ ਥਾਂ ਸਪਸ਼ਟ ਬੰਦ ਰੱਖੇ।
ਨਵੇਂ ਨਿਕਾਸ ਨੂੰ ਨਵੀਂ ਬੇਨਤੀ ਨਾਲ ਸਾਬਤ ਕਰੋ
ਮਹੱਤਵਪੂਰਨ ਗੱਲ ਇਹ ਹੈ ਕਿ ਬੇਨਤੀ ਸਰਗਰਮ ਕਰਨ ਤੋਂ ਬਾਅਦ ਖੋਲ੍ਹੀ ਗਈ ਹੋਵੇ, ping ਨਹੀਂ ਅਤੇ ਪਹਿਲਾਂ ਹੀ ਕੈਸ਼ ਹੋਇਆ ਪੰਨਾ ਨਹੀਂ। ਪ੍ਰੌਕਸੀ ਨੂੰ ਅਸਲੀ URL ਮੰਗੋ ਅਤੇ ਦੂਰਲਾ ਸਿਰਾ ਜੋ ਨਿਕਾਸ ਪਤਾ ਦੱਸਦਾ ਹੈ ਪੜ੍ਹੋ, ਫਿਰ ਜਦੋਂ ਪ੍ਰਦਾਤਾ ਇੱਕ ਦਿਖਾਏ ਤਾਂ ਕਲਾਇੰਟ ਦੇ ਟਨਲ ਬਾਰੇ ਆਪਣੇ ਦ੍ਰਿਸ਼ਟੀਕੋਣ ਨਾਲ ਤੁਲਨਾ ਕਰੋ।
ਪਾਰਸਿੰਗ, ਮੁੜ ਲੋਡ ਅਤੇ ਬੇਨਤੀ ਨੂੰ ਵੱਖਰੇ ਆਦੇਸ਼ ਰੱਖੋ ਤਾਂ ਜੋ ਫੇਲ੍ਹਤਾ ਇੱਕ ਕਦਮ ਵੱਲ ਇਸ਼ਾਰਾ ਕਰੇ। ਪਹਿਲੇ ਦੋ ਫੇਲ੍ਹ ਹੋਣ 'ਤੇ ਕੁਝ ਨਹੀਂ ਬਦਲਦੇ, ਅਤੇ ਇਸੇ ਲਈ ਉਹ ਮੁੜ ਚਾਲੂ ਕਰਨ ਤੋਂ ਪਹਿਲਾਂ ਚੱਲਦੇ ਹਨ।
squid -k parse
sudo squid -k reconfigure
curl -x http://127.0.0.1:3128 -sS -o /dev/null -w '%{http_code} %{remote_ip}\n' https://example.comਜੇ ਮੁੜ ਲੋਡ ਫੇਲ੍ਹ ਹੋਵੇ ਤਾਂ ਸੇਵਾ ਰੋਕੋ ਅਤੇ ਟੁਕੜਾ ਠੀਕ ਕਰੋ; ਪੁਰਾਣੇ ਨਿਕਾਸ ਨਾਲ ਸੇਵਾ ਦੇਣ ਵਾਲੀ ਪ੍ਰੌਕਸੀ ਥੋੜ੍ਹੇ ਵਿਘਨ ਨਾਲੋਂ ਮਾੜੀ ਹੈ। ਜੇ ਮੁੜ ਲੋਡ ਸਫਲ ਹੋਵੇ ਪਰ ਨਵੀਂ ਬੇਨਤੀ ਅਜੇ ਵੀ ਕਿਤੇ ਅਣਕਿਆਸੇ ਬਾਹਰ ਜਾਂਦੀ ਹੈ, ਤਾਂ ਪਤੇ ਮੁੜ ਸੋਧਣ ਦੀ ਥਾਂ ਰਾਊਟਿੰਗ ਜਾਂਚ ਵੱਲ ਵਾਪਸ ਜਾਓ। ਤੁਸੀਂ ਜਿਸ ਟਨਲ ਪੀੜ੍ਹੀ ਦੇ ਵਿਰੁੱਧ ਜਾਂਚ ਕੀਤੀ ਉਹ ਦਰਜ ਕਰੋ, ਤਾਂ ਜੋ ਅਗਲੀ ਮੁੜ ਜੁੜਨ ਵੇਲੇ ਤੁਲਨਾ ਲਈ ਠੋਸ ਕੁਝ ਹੋਵੇ।