Safari ਖੋਜ ਕਲਿੱਕ ਨੂੰ ਇਸ ਦੇ ਰੀਡਾਇਰੈਕਟਾਂ ਰਾਹੀਂ ਟ੍ਰੇਸ ਕਰੋ
ਖੋਜ ਕਲਿੱਕ ਪੇਜ ਤੱਕ ਪਹੁੰਚਣ ਤੋਂ ਪਹਿਲਾਂ ਰੀਡਾਇਰੈਕਟਰ, ਸਹਿਮਤੀ ਪੇਜ ਜਾਂ ਸਾਈਨ-ਇਨ ਵਿੱਚੋਂ ਲੰਘ ਸਕਦਾ ਹੈ। ਕਲਿੱਕ ਕੀਤੀ ਚੇਨ ਦੀ ਸਿੱਧੀ ਫੇਰੀ ਨਾਲ ਤੁਲਨਾ ਕਰੋ ਅਤੇ ਅਸਫਲ ਹੋਣ ਵਾਲੇ ਪੜਾਅ ਦਾ ਨਾਮ ਦਿਓ।
ਖੋਜ ਨਤੀਜੇ ਸ਼ਾਇਦ ਹੀ ਉਸ ਪੇਜ ਨਾਲ ਸਿੱਧਾ ਲਿੰਕ ਕਰਦੇ ਹਨ ਜਿਸ ਦਾ ਉਹ ਨਾਮ ਲੈਂਦੇ ਹਨ। ਇੱਕ ਕਲਿੱਕ ਰੀਡਾਇਰੈਕਟਰ, ਸਹਿਮਤੀ ਦੇ ਵਿਚਕਾਰਲੇ ਪੇਜ ਜਾਂ ਸਾਈਨ-ਇਨ ਸੇਵਾ ਵਿੱਚੋਂ ਲੰਘ ਸਕਦਾ ਹੈ, ਅਤੇ ਹਰ ਹੌਪ ਇੱਕ ਵੱਖਰੀ ਬੇਨਤੀ ਹੈ ਜੋ ਆਪਣੇ ਆਪ ਅਸਫਲ ਹੋ ਸਕਦੀ ਹੈ। Safari ਦਾ Network ਟੈਬ ਉਸ ਕ੍ਰਮ ਨੂੰ ਦਿਖਾਈ ਦਿੰਦਾ ਰੱਖਦਾ ਹੈ, ਪਰ ਕੇਵਲ ਤਦ ਜਦੋਂ ਤੁਸੀਂ ਕਲਿੱਕ ਤੋਂ ਪਹਿਲਾਂ ਰਿਕਾਰਡਿੰਗ ਸ਼ੁਰੂ ਕਰੋ। ਪਹਿਲਾ ਅਸਫਲ URL ਹੀ ਲਾਭਦਾਇਕ ਸਬੂਤ ਹੈ, ਨਤੀਜੇ ਵਿੱਚ ਦਿਖਾਇਆ ਪਤਾ ਨਹੀਂ।
ਕਲਿੱਕ ਤੋਂ ਪਹਿਲਾਂ ਰਿਕਾਰਡਿੰਗ ਸ਼ੁਰੂ ਕਰੋ
ਟੈਬ 'ਤੇ Web Inspector ਖੋਲ੍ਹੋ ਅਤੇ ਖੋਜ ਨਤੀਜੇ ਨੂੰ ਛੂਹਣ ਤੋਂ ਪਹਿਲਾਂ Network 'ਤੇ ਜਾਓ। Preserve Log ਚਾਲੂ ਕਰੋ ਤਾਂ ਜੋ ਸੂਚੀ ਪੇਜ ਨੂੰ ਬਦਲਣ ਵਾਲੀ ਨੈਵੀਗੇਸ਼ਨ ਤੋਂ ਬਾਅਦ ਵੀ ਰਹੇ। ਮੌਜੂਦਾ ਐਂਟਰੀਆਂ ਸਾਫ਼ ਕਰੋ, ਫਿਰ ਠੀਕ ਇੱਕ ਕਲਿੱਕ ਕਰੋ। ਪੇਜ ਲੋਡ ਹੋਣ ਤੋਂ ਬਾਅਦ ਸ਼ੁਰੂ ਹੋਈ ਰਿਕਾਰਡਿੰਗ ਤੁਹਾਨੂੰ ਲੋੜੀਂਦੀ ਬੇਨਤੀ ਪਹਿਲਾਂ ਹੀ ਗੁਆ ਚੁੱਕੀ ਹੈ।
ਬਿਨਾਂ ਨਿੱਜੀ ਡੇਟਾ ਵਾਲਾ ਪੇਜ ਵਰਤੋ ਅਤੇ ਪੂਰੀ ਤੁਲਨਾ ਦੌਰਾਨ ਬ੍ਰਾਊਜ਼ਰ ਪਰੋਫਾਈਲ ਅਤੇ VPN ਸਥਿਤੀ ਬਦਲੋ ਨਾ। ਇਨ੍ਹਾਂ ਵਿੱਚੋਂ ਕੋਈ ਇੱਕ ਵਿਚਕਾਰ ਬਦਲਣ ਨਾਲ ਦੋਵੇਂ ਰਾਹ ਤੁਲਨਾਯੋਗ ਨਹੀਂ ਰਹਿੰਦੇ।
ਰੀਡਾਇਰੈਕਟ ਕ੍ਰਮ ਵਿੱਚ ਪੜ੍ਹੋ
ਕਤਾਰਾਂ ਉੱਪਰ ਤੋਂ ਹੇਠਾਂ ਪੜ੍ਹੋ ਅਤੇ ਸਥਿਤੀ ਕੋਡ ਦੀ ਪਾਲਣਾ ਕਰੋ। ਜਿਸ ਦਾ Location ਖੇਤਰ ਕਿਸੇ ਹੋਰ ਹੋਸਟ ਵੱਲ ਇਸ਼ਾਰਾ ਕਰਦਾ ਹੈ, ਉਹ 301 ਜਾਂ 302 ਹੌਪ ਹੈ, ਮੰਜ਼ਿਲ ਨਹੀਂ। ਉਸ ਤੋਂ ਬਾਅਦ ਦੀ ਬੇਨਤੀ ਆਪਣੀ ਨਾਮ-ਖੋਜ, TLS ਹੈਂਡਸ਼ੇਕ ਅਤੇ ਨੀਤੀ ਜਾਂਚਾਂ ਵਾਲੀ ਨਵੀਂ ਨੈਵੀਗੇਸ਼ਨ ਹੈ। ਸਮੱਗਰੀ ਆਉਣ ਤੋਂ ਪਹਿਲਾਂ ਕਲਿੱਕ ਕਿੰਨੇ ਹੋਸਟਾਂ ਨੂੰ ਛੂਹਦਾ ਹੈ, ਗਿਣੋ।
WebKit ਦਾ Network ਟੈਬ ਗਾਈਡ ਦੱਸਦਾ ਹੈ ਕਿ ਬੇਨਤੀ ਰਿਕਾਰਡ ਅਤੇ Preserve Log ਚੋਣ ਕਿਵੇਂ ਵਿਵਹਾਰ ਕਰਦੇ ਹਨ, ਜੋ ਵਿਰਲ ਸੂਚੀ ਦੀ ਵਿਆਖਿਆ ਤੋਂ ਪਹਿਲਾਂ ਪੜ੍ਹਨ ਯੋਗ ਹੈ। ਗੁੰਮ ਕਤਾਰਾਂ ਦਾ ਆਮ ਅਰਥ ਹੈ ਕਿ ਰਿਕਾਰਡਿੰਗ ਦੇਰ ਨਾਲ ਸ਼ੁਰੂ ਹੋਈ ਜਾਂ service worker ਨੇ ਕੈਸ਼ ਤੋਂ ਜਵਾਬ ਦਿੱਤਾ, ਬ੍ਰਾਊਜ਼ਰ ਨੇ ਹੌਪ ਛੱਡਿਆ ਨਹੀਂ।
ਸਿੱਧੀ ਨੈਵੀਗੇਸ਼ਨ ਨਾਲ ਤੁਲਨਾ ਕਰੋ
ਉਸੇ ਪਰੋਫਾਈਲ ਅਤੇ ਨੈੱਟਵਰਕ ਹੇਠ ਲੋੜੀਂਦੇ ਅੰਤਿਮ ਪੇਜ 'ਤੇ ਦੂਜਾ ਪਾਸ ਕਰੋ, ਸਿੱਧਾ ਟਾਈਪ ਜਾਂ ਪੇਸਟ ਕਰਕੇ। ਦੋਵੇਂ ਸੂਚੀਆਂ ਜਿੱਥੇ ਵੱਖ ਹੁੰਦੀਆਂ ਹਨ, ਉਸ ਪਹਿਲੀ ਕਤਾਰ ਤੋਂ ਤੁਲਨਾ ਕਰੋ। ਜੇ ਕਲਿੱਕ ਕੀਤਾ ਰਾਹ ਅਜਿਹੇ ਵਿਚੋਲੇ 'ਤੇ ਅਸਫਲ ਹੁੰਦਾ ਹੈ ਜਿਸ ਨੂੰ ਸਿੱਧਾ ਰਾਹ ਕਦੇ ਨਹੀਂ ਛੂਹਦਾ, ਸਮੱਸਿਆ ਉਸ ਵਿਚੋਲੇ 'ਤੇ ਹੈ। ਜੇ ਦੋਵੇਂ ਇੱਕੋ origin ਤੱਕ ਪਹੁੰਚਦੇ ਹਨ ਅਤੇ ਸਿਰਫ਼ ਇੱਕ ਨੂੰ ਇਨਕਾਰ ਮਿਲਦਾ ਹੈ, ਤਾਂ ਖਾਤਾ ਸਥਿਤੀ ਜਾਂ ਬੇਨਤੀ ਵੇਰਵਾ ਵਧੀਆ ਸੁਰਾਗ ਹੈ।
ਦੋਵੇਂ ਰਿਕਾਰਡਿੰਗਾਂ ਨੂੰ ਸਮਾਂ-ਛਾਪਾਂ ਨਾਲ ਨਾਲ ਰੱਖੋ। ਸਮੇਂ ਦਾ ਫ਼ਰਕ ਕਾਰਨ ਦਾ ਸਬੂਤ ਨਹੀਂ, ਪਰ ਇਹ ਸੀਮਤ ਕਰਦਾ ਹੈ ਕਿ ਅੱਗੇ ਕਿਹੜੀ ਸੇਵਾ ਦੀ ਜਾਂਚ ਕਰਨੀ ਹੈ। ਨੋਟ ਕਰੋ ਕਿ ਹਰ ਅਸਫਲ ਕਤਾਰ ਕਿਹੜੇ ਹੋਸਟ ਦੀ ਸੀ, ਕਿਉਂਕਿ ਇੱਕੋ ਬ੍ਰਾਊਜ਼ਰ ਲੱਛਣ ਦੇ ਵੱਖ-ਵੱਖ ਪੜਾਵਾਂ 'ਤੇ ਵੱਖ-ਵੱਖ ਮਾਲਕ ਹੁੰਦੇ ਹਨ। ਜੇ ਸਿੱਧਾ ਪਾਸ ਵੀ ਅਸਫਲ ਹੋਵੇ, ਤਾਂ ਕਲਿੱਕ ਰਾਹ ਭੇਦਕ ਨਹੀਂ।
ਅਸਫਲਤਾ ਦੇ ਪੜਾਅ ਦਾ ਸਹੀ ਨਾਮ ਦਿਓ
ਕਤਾਰ ਦਾ ਗਲਤੀ ਪਾਠ ਸਾਈਟ ਬਲਾਕ ਹੋਣ ਦੇ ਆਮ ਦਾਅਵੇ ਨਾਲੋਂ ਵਧੇਰੇ ਵਿਸ਼ੇਸ਼ ਹੈ। ਨਾਮ-ਹੱਲ ਦੀ ਅਸਫਲਤਾ, ਕਦੇ ਪੂਰਾ ਨਾ ਹੋਣ ਵਾਲਾ ਕਨੈਕਸ਼ਨ, TLS ਗਲਤੀ ਅਤੇ HTTP ਸਥਿਤੀ ਚਾਰ ਵੱਖਰੇ ਪੜਾਅ ਹਨ ਜਿਨ੍ਹਾਂ ਦੇ ਚਾਰ ਵੱਖਰੇ ਮਾਲਕ ਹਨ। ਉਸ ਪੜਾਅ ਨੂੰ ਆਮ ਅਸਫਲਤਾ ਵਜੋਂ ਨਹੀਂ, ਸ਼ਬਦਾਂ ਵਿੱਚ ਦਰਜ ਕਰੋ, ਫਿਰ ਐਸਕਲੇਸ਼ਨ ਦਾ ਟੀਚਾ ਸਪਸ਼ਟ ਹੋ ਜਾਂਦਾ ਹੈ।
| Stage | What the row shows | Who owns it |
|---|---|---|
| Name resolution | No address, request never starts | Resolver or local DNS policy |
| Connection | Address known, transport never completes | Route, firewall or upstream reachability |
| TLS | Handshake error or certificate warning | Interception, clock or certificate trust |
| HTTP | A status code comes back | Origin, gateway or account policy |
Ping ਅਤੇ traceroute ਹੋਸਟ ਬਾਰੇ ਸੁਰਾਗ ਜੋੜ ਸਕਦੇ ਹਨ, ਪਰ ਉਹ ਬ੍ਰਾਊਜ਼ਰ ਦੀ ਰੀਡਾਇਰੈਕਟ ਚੇਨ ਮੁੜ ਨਹੀਂ ਚਲਾਉਂਦੇ ਅਤੇ ਇਹ ਸਾਬਤ ਨਹੀਂ ਕਰਦੇ ਕਿ HTTPS ਬੇਨਤੀ ਸਫਲ ਹੁੰਦੀ ਹੈ। ਹੋਸਟ ਨੂੰ ਸਫਲ ping ਉਸੇ ਹੋਸਟ 'ਤੇ TLS ਅਸਫਲਤਾ ਨਾਲ ਵੀ ਹੋ ਸਕਦਾ ਹੈ। ਵੈੱਬ-ਬੇਨਤੀ ਰਿਕਾਰਡ ਨੂੰ ਮੁੱਖ ਸਬੂਤ ਰੱਖੋ ਅਤੇ ਅੱਗੇ ਦੀਆਂ ਨੈੱਟਵਰਕ ਜਾਂਚਾਂ ਨੂੰ ਸਹਾਇਕ ਵੇਰਵਾ ਮੰਨੋ।
ਟੋਕਨ ਲੀਕ ਕੀਤੇ ਬਿਨਾਂ ਟ੍ਰੇਸ ਸਾਂਝਾ ਕਰੋ
ਟ੍ਰੇਸ ਨਿਰਯਾਤ ਜਾਂ ਪੇਸਟ ਕਰਨ ਤੋਂ ਪਹਿਲਾਂ ਹਰ URL, ਹੈਡਰ ਅਤੇ ਕੁਐਰੀ ਪੈਰਾਮੀਟਰ ਦੀ ਸਮੀਖਿਆ ਕਰੋ। ਰੀਡਾਇਰੈਕਟ ਚੇਨਾਂ ਅਕਸਰ ਸੈਸ਼ਨ ਪਛਾਣਕਰਤਾ, ਈਮੇਲ ਪਤੇ, ਸਹਿਮਤੀ ਸਥਿਤੀ ਜਾਂ ਦਸਤਖ਼ਤ ਕੀਤੇ ਲਿੰਕ ਲੈ ਕੇ ਜਾਂਦੀਆਂ ਹਨ। ਉਹ ਮੁੱਲ ਬਦਲੋ ਜਾਂ ਛਾਂਟੋ, ਅਤੇ ਜਾਂਚ ਨੂੰ ਸੱਚਮੁੱਚ ਲੋੜੀਂਦਾ origin, ਸਥਿਤੀ ਅਤੇ ਸਮਾਂ ਰੱਖੋ।
ਪਹਿਲੀ ਅਸਫਲ ਬੇਨਤੀ, ਉਸ ਤੋਂ ਪਹਿਲਾਂ ਦਾ ਹੌਪ ਅਤੇ ਰੀਡਾਇਰੈਕਟ ਸਥਿਤੀ ਸੌਂਪੋ। ਇਹ ਤਿੱਕੜੀ ਅਗਲੇ ਵਿਅਕਤੀ ਨੂੰ ਪੂਰੀ ਟ੍ਰੇਸ ਪੜ੍ਹੇ ਜਾਂ ਖਾਤੇ ਨੂੰ ਛੂਹੇ ਬਿਨਾਂ ਤੁਹਾਡਾ ਰਾਹ ਮੁੜ ਬਣਾਉਣ ਦਿੰਦੀ ਹੈ।