ਕੁਝ ਵੈੱਬਸਾਈਟਾਂ ਸਿਰਫ਼ VPN ਚਾਲੂ ਹੋਣ 'ਤੇ ਹੀ ਕਿਉਂ ਫੇਲ੍ਹ ਹੁੰਦੀਆਂ ਹਨ?

ਇੱਕ ਸਾਈਟ ਦਾ ਫੇਲ੍ਹ ਹੋਣਾ ਜਦੋਂ ਬਾਕੀ ਸਭ ਲੋਡ ਹੋ ਰਿਹਾ ਹੋਵੇ, ਇਹ ਸਾਬਤ ਕਰਦਾ ਹੈ ਕਿ ਟਨਲ ਟ੍ਰੈਫਿਕ ਲੈ ਜਾ ਰਹੀ ਹੈ, ਅਤੇ ਇਹ ਸਮੱਸਿਆ ਨੂੰ ਬਹੁਤਿਆਂ ਦੇ ਅੰਦਾਜ਼ੇ ਤੋਂ ਵੱਧ ਸੀਮਿਤ ਕਰਦਾ ਹੈ। ਤਿੰਨ ਨਿਰੀਖਣ ਬਾਕੀ ਨੂੰ ਸੰਭਾਲਦੇ ਹਨ: ਤੁਹਾਨੂੰ HTTP ਜਵਾਬ ਮਿਲਿਆ ਕਿ ਨਹੀਂ, ਹੋਸਟਨਾਮ ਪਤੇ ਵਿੱਚ ਹੱਲ ਹੋਇਆ ਕਿ ਨਹੀਂ, ਅਤੇ ਛੋਟੀਆਂ ਬੇਨਤੀਆਂ ਲੰਘਦੀਆਂ ਹਨ ਜਦੋਂ ਵੱਡੀਆਂ ਅਟਕਦੀਆਂ ਹਨ ਕਿ ਨਹੀਂ। ਇਹਨਾਂ ਜਵਾਬਾਂ ਤੋਂ ਪਹਿਲਾਂ VPN ਬਾਰੇ ਅੰਦਾਜ਼ਾ ਲਾਉਣਾ ਆਮ ਤੌਰ 'ਤੇ ਖਰਾਬੀ ਨੂੰ ਹਟਾਉਣ ਦੀ ਬਜਾਏ ਉਸਦੀ ਥਾਂ ਬਦਲਦਾ ਹੈ।

ਨਿਰੀਖਣਾਂ ਨੂੰ ਕ੍ਰਮ ਵਿੱਚ ਸੰਭਾਲੋ, ਕਿਉਂਕਿ ਜਿਸ ਸਾਈਟ ਨੇ ਜਵਾਬ ਦਿੱਤਾ ਉਹ ਉਸੇ ਸਮੇਂ ਹੱਲ ਵਿੱਚ ਫੇਲ੍ਹ ਨਹੀਂ ਹੋ ਸਕਦੀ। ਜੇ ਕੁਝ ਵੀ ਲੋਡ ਨਾ ਹੋਵੇ, ਤਾਂ ਤੁਸੀਂ ਗਲਤ ਸ਼ਾਖਾ ਵਿੱਚ ਹੋ, ਅਤੇ ਜੁੜਿਆ ਪਰ ਇੰਟਰਨੈਟ ਤੋਂ ਬਿਨਾਂ ਵਾਲੀਆਂ ਜਾਂਚਾਂ ਲਾਗੂ ਹੁੰਦੀਆਂ ਹਨ।

ਗਲਤੀ ਸੁਨੇਹੇ ਨੂੰ ਸ਼ਾਖਾ ਚੁਣਨ ਦਿਓ

ਇਨਕਾਰ, ਬੋਟ-ਚੁਣੌਤੀ ਜਾਂ ਗਲਤੀ ਪੰਨਾ ਮਤਲਬ ਹੈ ਕਿ ਸੇਵਾ ਨੇ ਜਵਾਬ ਦਿੱਤਾ, ਯਾਨੀ ਪੈਕਟ ਕਿਸੇ ਐਪਲੀਕੇਸ਼ਨ ਤੱਕ ਪਹੁੰਚੇ ਤੇ ਵਾਪਸ ਆਏ। ਇਹ ਸਵਾਲ ਨੂੰ ਸਾਈਟ ਦੀ ਪਹੁੰਚ ਨੀਤੀ ਵੱਲ ਲੈ ਜਾਂਦਾ ਹੈ, ਜੋ ਨਿਕਾਸ ਪਤਾ, ਖਾਤਾ ਜਾਂ ਪ੍ਰਕਾਸ਼ਿਤ ਨਾ ਕੀਤੇ ਬੇਨਤੀ ਪੈਟਰਨ ਤੋਲ ਸਕਦੀ ਹੈ। ਨਾਮ-ਹੱਲ ਦੀ ਫੇਲ੍ਹਤਾ ਸਾਈਟ ਤੱਕ ਕਦੇ ਨਹੀਂ ਪਹੁੰਚੀ, ਅਤੇ ਪਤਾ ਹੀ ਸਭ ਤੋਂ ਪਹਿਲਾਂ ਜਾਂਚਣ ਵਾਲੀ ਚੀਜ਼ ਹੈ। ਟਾਈਮਆਊਟ ਦੋਹਾਂ ਵਿਚਕਾਰ ਹੈ: ਕੁਝ ਭੇਜਿਆ ਗਿਆ ਅਤੇ ਕਿਸੇ ਨੇ ਇਸਦੀ ਪੁਸ਼ਟੀ ਨਹੀਂ ਕੀਤੀ।

ਸਰਟੀਫਿਕੇਟ ਚੇਤਾਵਨੀਆਂ ਚੌਥੀ ਸ਼ਾਖਾ ਦੀਆਂ ਹਨ। ਇਹਨਾਂ ਦਾ ਮਤਲਬ ਹੈ ਕਿ ਜਿਸ ਚੀਜ਼ ਦੀ ਪਛਾਣ ਬ੍ਰਾਊਜ਼ਰ ਪਰਖ ਨਹੀਂ ਸਕਿਆ ਉਸਨੇ ਕਨੈਕਸ਼ਨ ਦਾ ਜਵਾਬ ਦਿੱਤਾ, ਯਾਨੀ ਜਾਂ ਤਾਂ ਤੁਹਾਡੇ ਪਾਸੇ ਦਾ ਪ੍ਰੌਕਸੀ ਜਾਂ ਅਸਲ ਬੇਮੇਲ ਜਿਸ ਨੂੰ ਕਲਿੱਕ ਕਰਕੇ ਪਾਰ ਨਹੀਂ ਕਰਨਾ ਚਾਹੀਦਾ। ਇਸਨੂੰ ਰੂਟਿੰਗ ਦਾ ਨਹੀਂ, ਭਰੋਸੇ ਦਾ ਸਵਾਲ ਮੰਨੋ।

ਜਵਾਬ ਦੇਣ ਵਾਲੀ ਸਾਈਟ ਨੇ ਟੁੱਟੀ ਟਨਲ ਸਾਬਤ ਨਹੀਂ ਕੀਤੀ

ਜਦੋਂ ਜਵਾਬ ਬਲਾਕ ਪੰਨਾ ਹੋਵੇ, ਤਾਂ ਬ੍ਰਾਊਜ਼ਰ ਤੇ ਮਸ਼ੀਨ ਨੂੰ ਬਿਨਾਂ ਬਦਲੇ ਉਹੀ ਪੰਨਾ ਦੂਜੇ ਨਿਕਾਸ ਰਾਹੀਂ ਤੁਲਨਾ ਕਰੋ। ਜੇ ਨਤੀਜਾ ਨਿਕਾਸ ਪਤੇ ਦੇ ਨਾਲ ਚੱਲਦਾ ਹੈ, ਤਾਂ ਸਾਈਟ ਉਸ ਪਤੇ ਨਾਲ ਵੱਖਰਾ ਵਿਵਹਾਰ ਕਰ ਰਹੀ ਹੈ, ਅਤੇ ਕੋਈ ਕਲਾਇੰਟ ਸੰਰਚਨਾ ਇਸਨੂੰ ਨਹੀਂ ਬਦਲੇਗੀ। ਜੇ ਰੋਕ ਤੁਹਾਡੇ ਬ੍ਰਾਊਜ਼ਰ ਦੇ ਨਾਲ ਚੱਲਦੀ ਹੈ, ਤਾਂ ਕਾਰਨ ਐਕਸਟੈਂਸ਼ਨ, ਸੰਭਾਲਿਆ ਪ੍ਰੌਕਸੀ ਜਾਂ ਰਿਜ਼ੌਲਵਰ ਸੈਟਿੰਗ ਵਿੱਚ ਹੈ। ਦੋ ਦੌੜਾਂ ਇਹਨਾਂ ਵਿਆਖਿਆਵਾਂ ਨੂੰ ਸਸਤੇ ਵਿੱਚ ਵੱਖ ਕਰਦੀਆਂ ਹਨ।

ਸਿਰਫ਼ ਬ੍ਰਾਊਜ਼ਰ ਵਿੱਚ ਹੋਣ ਵਾਲੀਆਂ ਫੇਲ੍ਹਤਾਵਾਂ ਕਾਫ਼ੀ ਆਮ ਹਨ ਕਿ ਉਹਨਾਂ ਨੂੰ ਜਲਦੀ ਜਾਂਚਿਆ ਜਾਵੇ। ਕੋਈ ਪੰਨਾ ਇੱਕ ਸਮਰਥਿਤ ਬ੍ਰਾਊਜ਼ਰ ਵਿੱਚ ਲੋਡ ਹੋ ਕੇ ਦੂਜੇ ਵਿੱਚ ਫੇਲ੍ਹ ਹੋਵੇ, ਤਾਂ ਇਹ ਪ੍ਰੋਫਾਈਲ ਸਥਿਤੀ, ਸਮੱਗਰੀ-ਰੋਕ ਜਾਂ ਬ੍ਰਾਊਜ਼ਰ ਦੇ ਅੰਦਰ ਹੀ ਸੰਰਚਿਤ ਐਨਕ੍ਰਿਪਟਿਡ DNS ਵੱਲ ਇਸ਼ਾਰਾ ਕਰਦਾ ਹੈ। Chrome ਦੇ ਸੁਰੱਖਿਅਤ DNS ਸੰਬੰਧੀ ਨਿਰਦੇਸ਼ ਦੱਸਦੇ ਹਨ ਕਿ ਉਹ ਸੈਟਿੰਗ ਕਿੱਥੇ ਹੈ, ਅਤੇ ਇਸਨੂੰ ਸਮਰਥਿਤ ਨਿਯੰਤਰਣ ਰਾਹੀਂ ਬਦਲਣਾ ਡਿਵਾਈਸ ਰੀਸੈਟ ਕਰਨ ਤੋਂ ਬਿਹਤਰ ਹੈ।

ਜਦੋਂ ਸਿਰਫ਼ ਵੱਡੇ ਟ੍ਰਾਂਸਫਰ ਅਟਕਦੇ ਹਨ, ਪੈਕਟ ਦਾ ਆਕਾਰ ਵੇਖੋ

ਜਿਹੜਾ ਪੰਨਾ ਆਪਣਾ ਹੈਡਰ ਬਣਾ ਕੇ ਫਿਰ ਅਟਕ ਜਾਂਦਾ ਹੈ, ਉਸਦਾ ਦਸਤਖਤ ਕਦੇ ਸ਼ੁਰੂ ਨਾ ਹੋਣ ਵਾਲੇ ਪੰਨੇ ਨਾਲੋਂ ਵੱਖਰਾ ਹੁੰਦਾ ਹੈ। ਛੋਟੇ ਜਵਾਬ ਲੰਘ ਸਕਦੇ ਹਨ ਜਦੋਂ ਪੂਰੇ ਆਕਾਰ ਦਾ ਪੇਲੋਡ ਕਿਤੇ ਸੁੱਟਿਆ ਜਾਂਦਾ ਹੈ ਜੋ ਭੇਜਣ ਵਾਲੇ ਨੂੰ ਸੰਕੇਤ ਨਹੀਂ ਦੇ ਸਕਦਾ, ਅਤੇ ਬ੍ਰਾਊਜ਼ਰ ਤੋਂ ਪਥ MTU ਫੇਲ੍ਹਤਾ ਇਸੇ ਤਰ੍ਹਾਂ ਦਿਸਦੀ ਹੈ। ਫਿਲਟਰਿੰਗ ਬਾਰੇ ਸਿਧਾਂਤ ਬਣਾਉਣ ਤੋਂ ਪਹਿਲਾਂ ਇੱਕੋ ਹੋਸਟ ਨੂੰ ਛੋਟੀ ਤੇ ਵੱਡੀ ਬੇਨਤੀ ਭੇਜ ਕੇ ਤੁਲਨਾ ਕਰੋ। ਪਥ MTU ਖੋਜ ਨੂੰ ਪਥ ਦੀ ਸਭ ਤੋਂ ਛੋਟੀ ਕੜੀ ਦਾ ਆਕਾਰ ਸਿੱਖਣਾ ਚਾਹੀਦਾ ਹੈ, ਅਤੇ ਇਹ ਫਿਲਟਰ ਕੀਤੇ ਨੈੱਟਵਰਕਾਂ ਵੱਲੋਂ ਨਿਯਮਿਤ ਸੁੱਟੇ ਜਾਂਦੇ ICMP ਜਵਾਬਾਂ 'ਤੇ ਨਿਰਭਰ ਹੈ।

ਉਸ ਪਰਿਕਲਪਨਾ ਨੂੰ ਇੱਕ ping ਦੀ ਬਜਾਏ ਆਕਾਰ-ਸਕੈਨ ਨਾਲ ਪਰਖੋ। ਸਥਿਰ ਪੇਲੋਡ ਆਕਾਰ 'ਤੇ ਸ਼ੁਰੂ ਹੋਣ ਵਾਲੀ ਫੇਲ੍ਹਤਾ ਮਜ਼ਬੂਤ ਸਬੂਤ ਹੈ, ਜਦੋਂ ਕਿ ਭਟਕਦੀ ਫੇਲ੍ਹਤਾ ਨਹੀਂ।

ਫੇਲ੍ਹ ਹੋਈ ਬੇਨਤੀ 'ਤੇ ਹੀ ਸੁਧਾਰ ਦੀ ਪੁਸ਼ਟੀ ਕਰੋ

ਮੂਲ ਕਾਰਵਾਈ ਦੁਬਾਰਾ ਪਰਖੋ, ਹੋਮਪੇਜ ਨਹੀਂ, ਕਿਉਂਕਿ ਕੈਸ਼ ਕੀਤਾ ਖੋਲ ਬਣ ਸਕਦਾ ਹੈ ਜਦੋਂ ਸਾਈਨ-ਇਨ ਪਿੱਛੇ ਦੀ API ਕਾਲ ਅਜੇ ਵੀ ਫੇਲ੍ਹ ਹੁੰਦੀ ਹੈ। ਹੇਠਾਂ ਦਿੱਤੇ ਹੁਕਮ ਇੱਕੋ ਹੋਸਟ 'ਤੇ ਨਾਮ-ਹੱਲ, ਛੋਟੀ ਬੇਨਤੀ ਤੇ ਵੱਡੀ ਬੇਨਤੀ ਨੂੰ ਵੱਖ ਕਰਦੇ ਹਨ। ਹੋਸਟਨਾਮ ਤੇ ਪਥ ਨੂੰ ਸੱਚਮੁੱਚ ਟੁੱਟੀ ਬੇਨਤੀ ਦੇ ਮੁੱਲਾਂ ਨਾਲ ਬਦਲੋ।

dig +short www.example.com
curl -sS -o /dev/null -w '%{http_code} %{time_total}\n' https://www.example.com/
curl -sS -o /dev/null -w '%{http_code} %{size_download}\n' https://www.example.com/assets/app.js
ping -M do -s 1400 -c 3 203.0.113.20

ਜੇ dig ਦਾ ਜਵਾਬ ਬ੍ਰਾਊਜ਼ਰ ਵੱਲੋਂ ਵਰਤੇ ਨਾਲੋਂ ਵੱਖਰਾ ਹੋਵੇ, ਤਾਂ ਰਿਜ਼ੌਲਵਰ ਚਲ ਹੈ, ਅਤੇ ਬ੍ਰਾਊਜ਼ਰ ਦੀ ਆਪਣੀ DNS ਸੈਟਿੰਗ ਵੇਖਣ ਦੀ ਥਾਂ ਹੈ। ਜੇ ਛੋਟੀ ਬੇਨਤੀ ਸਥਿਤੀ ਮੋੜਦੀ ਹੈ ਜਦੋਂ ਵੱਡੀ ਅਟਕਦੀ ਹੈ, ਤਾਂ ਪੈਕਟ-ਆਕਾਰ ਸ਼ਾਖਾ 'ਤੇ ਕੰਮ ਕਰੋ। ਜੇ ਦੋਵੇਂ ਸਮਾਂ ਖਤਮ ਕਰ ਦੇਣ, ਤਾਂ ਨਿਕਾਸ ਪਥ ਤੇ ਉਸ ਪਤੇ ਪ੍ਰਤੀ ਸਾਈਟ ਦਾ ਰਵੱਈਆ ਫਿਰ ਮੇਜ਼ 'ਤੇ ਹਨ।

ਜਿਸ ਬਦਲਾਅ ਨੇ ਮੂਲ ਬੇਨਤੀ ਨੂੰ ਸਫਲ ਕੀਤਾ ਉਹ ਰੱਖੋ ਤੇ ਬਾਕੀ ਵਾਪਸ ਕਰੋ। ਬ੍ਰਾਊਜ਼ਰ, ਰਿਜ਼ੌਲਵਰ ਤੇ ਕਲਾਇੰਟ 'ਤੇ ਇਕੱਠੇ ਕੀਤੇ ਬਦਲਾਅਾਂ ਦਾ ਢੇਰ ਤੁਹਾਨੂੰ ਇਹ ਦੱਸਣ ਨਹੀਂ ਦਿੰਦਾ ਕਿ ਕਿਹੜਾ ਮਹੱਤਵਪੂਰਨ ਸੀ।