ਜਦੋਂ Chrome ਸਥਾਨਕ PAC ਫਾਈਲ ਲੋਡ ਨਹੀਂ ਕਰ ਸਕਦਾ
ਰੱਦ ਕੀਤੇ ਸਥਾਨਕ PAC ਫਾਈਲ URL ਨੂੰ PAC ਰੂਟਿੰਗ ਸਹਾਇਤਾ, ਸਕ੍ਰਿਪਟ ਸਿੰਟੈਕਸ ਅਤੇ ਚੁਣੇ ਪ੍ਰੌਕਸੀ ਤੋਂ ਵੱਖ ਕਰੋ।
ਜੇ Chrome file:// URL ਵਜੋਂ ਦਿੱਤੀ PAC ਸਕ੍ਰਿਪਟ ਵਰਤ ਨਹੀਂ ਸਕਦਾ, ਤਾਂ ਸਕ੍ਰਿਪਟ ਮੁੜ ਲਿਖਣ ਤੋਂ ਪਹਿਲਾਂ ਇਹ ਡਿਲਿਵਰੀ ਮਾਰਗ ਜਾਂਚੋ। ਇੱਕ ਥਾਂ ਲੋਡ ਨਾ ਹੋਣਾ ਇਹ ਸਾਬਤ ਨਹੀਂ ਕਰਦਾ ਕਿ PAC ਰੂਟਿੰਗ ਸਮਰਥਿਤ ਨਹੀਂ।
Chrome ਦੀ ਪ੍ਰੌਕਸੀ API ਵਿੱਚ pac_script ਮੋਡ ਹੈ; ਸਕ੍ਰਿਪਟ URL ਜਾਂ ਇਨਲਾਈਨ ਡੇਟਾ ਸਮਰਥਿਤ ਐਕਸਟੈਂਸ਼ਨ ਇੰਟਰਫੇਸ ਰਾਹੀਂ ਉਪਲਬਧ ਹੁੰਦਾ ਹੈ। ਓਪਰੇਟਿੰਗ ਸਿਸਟਮ ਸੈਟਿੰਗਾਂ ਰਾਹੀਂ ਦਿੱਤੀ ਸਥਾਨਕ ਫਾਈਲ ਸਕ੍ਰਿਪਟ ਪਹੁੰਚਾਉਣ ਦਾ ਸਿਰਫ਼ ਇੱਕ ਤਰੀਕਾ ਹੈ।
ਸਕ੍ਰਿਪਟ ਬ੍ਰਾਊਜ਼ਰ ਤੱਕ ਕਿਵੇਂ ਪਹੁੰਚਦੀ ਹੈ, ਇਹ ਦੇਖੋ
ਪ੍ਰਭਾਵਿਤ ਬ੍ਰਾਊਜ਼ਰ ਨੂੰ ਕੀ ਨਿਯੰਤਰਿਤ ਕਰਦਾ ਹੈ, ਇਹ ਪਤਾ ਕਰੋ: ਸਿਸਟਮ ਸੈਟਿੰਗਾਂ, ਪ੍ਰਬੰਧਿਤ ਨੀਤੀ, ਕਮਾਂਡ-ਲਾਈਨ ਸੰਰਚਨਾ ਜਾਂ ਐਕਸਟੈਂਸ਼ਨ। macOS ਸੈਟਿੰਗਾਂ ਵਿੱਚ ਦਿਖਦਾ ਮੁੱਲ ਇਹ ਸਾਬਤ ਨਹੀਂ ਕਰਦਾ ਕਿ Chrome ਨੇ ਉਹ ਸਕ੍ਰਿਪਟ ਪ੍ਰਾਪਤ ਕੀਤੀ ਤੇ ਮੁਲਾਂਕਣ ਕੀਤਾ।
ਰੱਦ ਕੀਤੇ ਜਾਂ ਪਹੁੰਚ ਤੋਂ ਬਾਹਰ ਸਕ੍ਰਿਪਟ ਟਿਕਾਣੇ ਨੂੰ ਮੁਲਾਂਕਣ ਗਲਤੀ ਤੋਂ, ਅਤੇ ਦੋਵਾਂ ਨੂੰ ਵੈਧ ਸਕ੍ਰਿਪਟ ਵੱਲੋਂ ਦਿੱਤੀ ਪ੍ਰੌਕਸੀ ਨਾਲ ਜੁੜਨ ਵਿੱਚ ਅਸਫਲਤਾ ਤੋਂ ਵੱਖ ਕਰੋ। SOCKS ਪੋਰਟ ਸਿਰਫ਼ ਬ੍ਰਾਊਜ਼ਰ ਵੱਲੋਂ ਉਹ ਰਸਤਾ ਚੁਣਨ ਮਗਰੋਂ ਹੀ ਮਹੱਤਵਪੂਰਨ ਹੁੰਦਾ ਹੈ।
ਪ੍ਰਬੰਧਿਤ PAC ਨੂੰ ਟਾਰਗਿਟ ਕਲਾਇੰਟਾਂ ਵੱਲੋਂ ਸਮਰਥਿਤ ਮਨਜ਼ੂਰਸ਼ੁਦਾ ਢਾਂਚੇ ਰਾਹੀਂ ਵੰਡੋ। ਜਿਸ ਪ੍ਰੌਕਸੀ ਦਾ ਇਹ ਵਰਣਨ ਕਰਦੀ ਹੈ ਉਹ ਉਪਲਬਧ ਨਾ ਹੋਣ ਵੇਲੇ ਵੀ HTTP ਜਾਂ HTTPS ਡਿਲਿਵਰੀ URL ਪਹੁੰਚਯੋਗ ਰਹਿਣੀ ਚਾਹੀਦੀ ਹੈ। ਐਕਸਟੈਂਸ਼ਨ ਵੱਲੋਂ ਦਿੱਤੇ ਇਨਲਾਈਨ ਡੇਟਾ ਵਿੱਚ ਅਸਲ ਫਾਈਲ ਬਦਲਣ ਨਾਲ ਕਾਪੀ ਕੀਤੀ ਸਕ੍ਰਿਪਟ ਆਪਣੇ ਆਪ ਅੱਪਡੇਟ ਨਹੀਂ ਹੁੰਦੀ। ਸ਼ੁਰੂਆਤ ਵੇਲੇ ਛੋਟੀ ਸਥਾਨਕ ਨੀਤੀ ਲਈ ਸਕ੍ਰਿਪਟ ਨੂੰ data URL ਵਿੱਚ ਸ਼ਾਮਲ ਕਰੋ — ਇਹ ਇੱਕ ਹੋਰ ਡਿਲਿਵਰੀ ਮਾਰਗ ਹੈ।
ਅੰਦਰੂਨੀ PAC ਵਿੱਚ ਨਿੱਜੀ ਹੋਸਟਨਾਂ ਅਤੇ ਰੂਟਿੰਗ ਨਿਯਮ ਹੋ ਸਕਦੇ ਹਨ। ਸਥਾਨਕ ਫਾਈਲ ਸਮੱਸਿਆ ਹੱਲ ਕਰਨ ਲਈ ਇਸਨੂੰ ਕਿਸੇ ਵੀ ਜਨਤਕ ਹੋਸਟਿੰਗ ਵੱਲ ਨਾ ਭੇਜੋ, ਸਗੋਂ ਮਨਜ਼ੂਰਸ਼ੁਦਾ ਡਿਲਿਵਰੀ ਸੇਵਾ ਉੱਤੇ ਰੱਖੋ।