ਨਿੱਜੀ API 'ਤੇ Requests ProxyError? ਪਹਿਲਾਂ ਵਾਤਾਵਰਣ ਦੀ ਜਾਂਚ ਕਰੋ

Requests ਵਾਤਾਵਰਣ ਤੋਂ ਪ੍ਰੌਕਸੀ, auth ਅਤੇ CA ਸੈਟਿੰਗਾਂ ਨੂੰ ਮਿਲਾਉਂਦਾ ਹੈ। ਪ੍ਰਕਿਰਿਆ ਜੋ ਦੇਖਦੀ ਹੈ ਉਹ ਪੜ੍ਹੋ, ਨਿੱਜੀ ਹੋਸਟ ਨੂੰ ਬਾਹਰ ਰੱਖੋ ਅਤੇ TLS ਜਾਂਚ ਚਾਲੂ ਰੱਖੋ।

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

ਉਹ ਵਾਤਾਵਰਣ ਪੜ੍ਹੋ ਜੋ ਪ੍ਰਕਿਰਿਆ ਅਸਲ ਵਿੱਚ ਦੇਖਦੀ ਹੈ

ਡੈਸਕਟਾਪ ਪ੍ਰੌਕਸੀ ਸੈਟਿੰਗਾਂ, shell ਐਕਸਪੋਰਟ ਅਤੇ systemd ਯੂਨਿਟ ਦੀਆਂ Environment= ਲਾਈਨਾਂ ਤਿੰਨ ਵੱਖਰੇ ਸਰੋਤ ਹਨ, ਅਤੇ Requests ਸਿਰਫ਼ ਆਖਰੀ ਵਿਰਾਸਤ ਵਿੱਚ ਮਿਲੀ ਲਾਈਨ ਪੜ੍ਹਦਾ ਹੈ। ਹੇਠਾਂ ਦਿੱਤੀ ਜਾਂਚ ਉਸੇ shell, ਕੰਟੇਨਰ ਜਾਂ ਯੂਨਿਟ ਵਿੱਚ ਚਲਾਓ ਜੋ ਅਸਫਲ ਸਕ੍ਰਿਪਟ ਚਲਾਉਂਦਾ ਹੈ, ਆਪਣੇ ਇੰਟਰਐਕਟਿਵ ਟਰਮੀਨਲ ਵਿੱਚ ਨਹੀਂ। ਤੁਹਾਡੇ ਲੌਗਇਨ shell ਵਿੱਚ ਐਕਸਪੋਰਟ ਕੀਤਾ ਵੇਰੀਏਬਲ ਕੰਟੇਨਰ ਪ੍ਰਕਿਰਿਆ ਲਈ ਅਦਿੱਖ ਹੈ, ਅਤੇ ਇਹੀ ਖਾਲੀ ਥਾਂ ਕਿਤੇ ਤੋਂ ਵੀ ਅਚਾਨਕ ਦਿਖਣ ਵਾਲੀ ਪ੍ਰੌਕਸੀ ਬਾਰੇ ਕਈ ਰਿਪੋਰਟਾਂ ਦੀ ਵਿਆਖਿਆ ਕਰਦੀ ਹੈ। ਦੋਵੇਂ ਹੁਕਮ ਉਹੀ ਡੇਟਾ ਵੱਖਰੇ ਵੇਰਵੇ ਪੱਧਰ 'ਤੇ ਛਾਪਦੇ ਹਨ।

env | grep -i -E 'proxy|requests_ca_bundle|curl_ca_bundle'
python3 -c "import os;[print(k,'=',v) for k,v in sorted(os.environ.items()) if 'proxy' in k.lower()]"

ਹਰ ਵੇਰੀਏਬਲ ਦੀਆਂ ਦੋਵੇਂ ਸਪੈਲਿੰਗਾਂ ਪੜ੍ਹੀਆਂ ਜਾਂਦੀਆਂ ਹਨ, ਅਤੇ ਡੁਪਲੀਕੇਟ ਐਂਟਰੀਆਂ ਉਸੇ ਕ੍ਰਮ ਵਿੱਚ ਲਾਗੂ ਹੁੰਦੀਆਂ ਹਨ ਜਿਸ ਵਿੱਚ ਪ੍ਰਕਿਰਿਆ ਨੂੰ ਮਿਲੀਆਂ, ਇਸ ਲਈ ਪੁਰਾਣਾ HTTP_PROXY ਹੁਣੇ ਐਕਸਪੋਰਟ ਕੀਤੇ ਮੁੱਲ ਨੂੰ ਓਵਰਰਾਈਡ ਕਰ ਸਕਦਾ ਹੈ। CA-ਬੰਡਲ ਵੇਰੀਏਬਲ ਇੱਥੇ ਵੀ ਮਹੱਤਵਪੂਰਨ ਹਨ, ਕਿਉਂਕਿ ਉਹ ਬਦਲਦੇ ਹਨ ਕਿ verify ਕਿਸ ਵਿੱਚ ਹੱਲ ਹੁੰਦਾ ਹੈ ਬਿਨਾਂ ਕੋਡ ਵਿੱਚ ਕਿਤੇ ਦਿਖੇ। ਜੇ ਆਉਟਪੁੱਟ ਖਾਲੀ ਹੈ, ਵਾਤਾਵਰਣ ਤੁਹਾਡੀ ਸਮੱਸਿਆ ਨਹੀਂ ਅਤੇ ਤੁਸੀਂ ਇਹ ਭਾਗ ਪੜ੍ਹਨਾ ਬੰਦ ਕਰ ਸਕਦੇ ਹੋ। ਜੇ ਇਹ ਕੋਈ ਅਜਿਹੀ ਪ੍ਰੌਕਸੀ ਸੂਚੀਬੱਧ ਕਰਦਾ ਹੈ ਜਿਸਨੂੰ ਤੁਸੀਂ ਨਹੀਂ ਪਛਾਣਦੇ, ਕੁਝ ਵੀ ਬਦਲਣ ਤੋਂ ਪਹਿਲਾਂ ਉਹ ਫਾਈਲ ਜਾਂ ਯੂਨਿਟ ਲੱਭੋ ਜੋ ਇਸਨੂੰ ਸੈਟ ਕਰਦੀ ਹੈ।

Requests ਨੂੰ ਪੁੱਛੋ ਕਿ ਇਹ ਕਿਸੇ ਖਾਸ URL ਨਾਲ ਕੀ ਕਰੇਗਾ। ਇਹ ਕਾਲ ਕੋਈ ਪੈਕੇਟ ਭੇਜੇ ਬਿਨਾਂ ਉਸ ਬੇਨਤੀ ਲਈ ਮਿਲਾਏ ਪ੍ਰੌਕਸੀ, verify ਅਤੇ cert ਮੁੱਲ ਦਿਖਾਉਂਦੀ ਹੈ।

python3 -c "import requests;s=requests.Session();print(s.merge_environment_settings('https://api.corp.example/status',{},None,None,None))"

ਨਿੱਜੀ ਹੋਸਟ ਲਈ ਖਾਲੀ ਨਾ ਹੋਣ ਵਾਲੀ proxies ਐਂਟਰੀ ਤੁਹਾਡਾ ਜਵਾਬ ਹੈ, ਅਤੇ ਛਾਪਿਆ verify ਮੁੱਲ ਦੱਸਦਾ ਹੈ ਕਿ ਬੇਨਤੀ ਕਿਸ CA-ਬੰਡਲ 'ਤੇ ਭਰੋਸਾ ਕਰੇਗੀ। ਜੇ ਦੋਵੇਂ ਸਹੀ ਲੱਗਦੇ ਹਨ, ਅਸਫਲਤਾ ਸਟੈਕ ਵਿੱਚ ਅੱਗੇ ਹੈ ਅਤੇ ਤੁਹਾਨੂੰ ਜਾਂਚ ਭਾਗ ਵੱਲ ਜਾਣਾ ਚਾਹੀਦਾ ਹੈ। ਕੋਡ ਤੋਂ ਅੰਦਾਜ਼ਾ ਨਾ ਲਾਓ: ਮਿਲਾਉਣਾ ਹਰ ਬੇਨਤੀ ਲਈ ਹੁੰਦਾ ਹੈ, ਇਸ ਲਈ ਇੱਕ ਸੈਸ਼ਨ ਦੋ ਹੋਸਟਾਂ ਲਈ ਵੱਖਰਾ ਵਿਵਹਾਰ ਕਰ ਸਕਦਾ ਹੈ।

ਕੁਝ ਵੀ ਬੰਦ ਕਰਨ ਤੋਂ ਪਹਿਲਾਂ ਨਿੱਜੀ ਹੋਸਟ ਨੂੰ ਬਾਹਰ ਰੱਖੋ

ਜਦੋਂ ਹੋਰ ਮੰਜ਼ਿਲਾਂ ਲਈ ਪ੍ਰੌਕਸੀ ਸੱਚਮੁੱਚ ਲੋੜੀਂਦੀ ਹੋਵੇ, ਤੰਗ ਹੱਲ ਇਸ ਹੋਸਟ ਲਈ ਬਾਹਰਲਾ ਕਰਨਾ ਹੈ। ਮੌਜੂਦਾ ਸੂਚੀ ਵਿੱਚ ਸ਼ਾਮਲ ਕਰੋ, ਇਸਨੂੰ ਬਦਲੋ ਨਹੀਂ, ਕਿਉਂਕਿ NO_PROXY ਮਿਟਾਉਣ ਨਾਲ ਉਸ 'ਤੇ ਨਿਰਭਰ ਹਰ ਹੋਰ ਅੰਦਰੂਨੀ ਮੰਜ਼ਿਲ ਟੁੱਟ ਜਾਂਦੀ ਹੈ। ਹੇਠਾਂ ਦਿੱਤੇ ਹੁਕਮ ਐਂਟਰੀ ਜੋੜਦੇ ਹਨ ਅਤੇ ਫਿਰ Requests ਨੂੰ ਪੁੱਛਦੇ ਹਨ ਕਿ ਬਾਈਪਾਸ ਲਾਗੂ ਹੁੰਦਾ ਹੈ ਜਾਂ ਨਹੀਂ।

export NO_PROXY="${NO_PROXY:+$NO_PROXY,}api.corp.example,.corp.example"
python3 -c "import requests;print(requests.utils.should_bypass_proxies('https://api.corp.example/status',None))"

ਮੇਲ ਹੋਸਟ ਸਫਿਕਸ ਅਨੁਸਾਰ ਹੁੰਦਾ ਹੈ, ਇਸ ਲਈ .corp.example ਪੂਰਾ ਡੋਮੇਨ ਕਵਰ ਕਰਦਾ ਹੈ ਜਦਕਿ api.corp.example ਇੱਕ ਨਾਮ ਕਵਰ ਕਰਦਾ ਹੈ। ਖਾਲੀ ਤਾਰਾ ਚਿੰਨ੍ਹ ਹਰ ਹੋਸਟ ਲਈ ਪ੍ਰੌਕਸੀ ਬੰਦ ਕਰਦਾ ਹੈ ਅਤੇ ਉਤਪਾਦਨ ਕੰਮ ਲਗਭਗ ਕਦੇ ਵੀ ਇਹ ਨਹੀਂ ਚਾਹੁੰਦਾ। CIDR ਐਂਟਰੀ ਮੰਨੀ ਜਾਵੇਗੀ ਜਾਂ ਨਹੀਂ ਇਹ ਇਮੇਜ ਵਿੱਚ Requests ਅਤੇ urllib3 ਵਰਜ਼ਨਾਂ 'ਤੇ ਨਿਰਭਰ ਕਰਦਾ ਹੈ, ਇਸ ਲਈ ਕੰਮ ਕਰਦਾ ਮੰਨਣ ਦੀ ਬਜਾਏ ਸਹੀ ਐਂਟਰੀ ਪਰਖੋ। should_bypass_proxies ਦਾ ਨਤੀਜਾ ਅਸਲ URL ਲਈ ਜਾਂਚੋ, ਯਾਦ ਤੋਂ ਟਾਈਪ ਕੀਤੇ ਹੋਸਟਨਾਮ ਲਈ ਨਹੀਂ।

ਦੋਵੇਂ ਪਰਤਾਂ ਨੂੰ ਮਨ ਵਿੱਚ ਵੱਖਰਾ ਰੱਖੋ। HTTP ਪ੍ਰੌਕਸੀ ਬਾਈਪਾਸ ਕਰਨਾ VPN ਬਾਈਪਾਸ ਨਹੀਂ ਕਰਦਾ, ਕਿਉਂਕਿ ਪ੍ਰੌਕਸੀ ਦਾ ਫੈਸਲਾ ਲਾਇਬ੍ਰੇਰੀ ਵਿੱਚ ਅਤੇ ਸੁਰੰਗ ਦਾ ਫੈਸਲਾ ਕਰਨਲ ਦੀ ਰੂਟਿੰਗ ਟੇਬਲ ਵਿੱਚ ਹੁੰਦਾ ਹੈ।

trust_env ਨੂੰ ਸਿਰਫ਼ ਜਾਣਬੁੱਝ ਕੇ ਲਏ ਸੈਸ਼ਨ ਨੀਤੀ ਵਜੋਂ ਬੰਦ ਕਰੋ

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

import requests

with requests.Session() as session:
    session.trust_env = False
    response = session.get(
        "https://api.corp.example/status",
        timeout=(5, 20),
        verify="/etc/ssl/certs/corp-ca.pem",
    )
    response.raise_for_status()

trust_env ਬੰਦ ਕਰਨ ਨਾਲ ਇੱਕੋ ਸਮੇਂ ਤਿੰਨ ਵਿਵਹਾਰ ਬਦਲਦੇ ਹਨ, ਅਤੇ ਉਨ੍ਹਾਂ ਵਿੱਚੋਂ ਸਿਰਫ਼ ਇੱਕ ਪ੍ਰੌਕਸੀ ਬਾਰੇ ਹੈ। Requests .netrc ਪ੍ਰਮਾਣ ਪੜ੍ਹਨਾ ਬੰਦ ਕਰ ਦਿੰਦਾ ਹੈ, ਅਤੇ REQUESTS_CA_BUNDLE ਤੇ CURL_CA_BUNDLE ਵੇਰੀਏਬਲ verify ਨੂੰ ਪ੍ਰਭਾਵਿਤ ਕਰਨਾ ਬੰਦ ਕਰ ਦਿੰਦੇ ਹਨ, ਜੋ ਫਿਰ ਨਾਲ ਆਏ ਸਰਟੀਫਿਕੇਟ ਸਟੋਰ 'ਤੇ ਵਾਪਸ ਜਾਂਦਾ ਹੈ। ਜੇ ਤੁਹਾਡੀ ਸੰਸਥਾ ਆਪਣੇ CA ਨਾਲ TLS ਖਤਮ ਕਰਦੀ ਹੈ, ਤਾਂ ਉਹ ਫਾਲਬੈਕ ਇੱਕ ਜਾਂਚ ਗਲਤੀ ਪੈਦਾ ਕਰਦਾ ਹੈ ਜੋ ਹੁਣੇ ਕੀਤੇ ਬਦਲਾਅ ਨਾਲ ਬੇਸੰਬੰਧ ਲੱਗਦੀ ਹੈ। verify ਸਪਸ਼ਟ ਰੂਪ ਵਿੱਚ ਭੇਜਣਾ ਹੀ ਦੋਵੇਂ ਪ੍ਰਭਾਵਾਂ ਨੂੰ ਵੱਖਰਾ ਰੱਖਦਾ ਹੈ।

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

ਅਸਫਲ ਪਰਤ ਦੀ ਜਾਂਚ ਕਰੋ ਅਤੇ ਵਾਪਸ ਮੁੜਨ ਦੀ ਸਮਰੱਥਾ ਰੱਖੋ

ਤਿੰਨ ਅਸਫਲਤਾਵਾਂ ਲੌਗ ਵਿੱਚ ਇੱਕੋ ਜਿਹੀਆਂ ਦਿਖਦੀਆਂ ਹਨ ਅਤੇ ਉਨ੍ਹਾਂ ਵਿੱਚ ਕੁਝ ਵੀ ਸਾਂਝਾ ਨਹੀਂ: ਮੰਜ਼ਿਲ ਤੱਕ ਨਾ ਪਹੁੰਚਣ ਵਾਲੀ ਪ੍ਰੌਕਸੀ ProxyError ਸੁੱਟਦੀ ਹੈ ਜਾਂ 502 ਵਾਪਸ ਕਰਦੀ ਹੈ, ਭਰੋਸੇ ਦੀ ਸਮੱਸਿਆ SSLError ਸੁੱਟਦੀ ਹੈ, ਅਤੇ ਐਪਲੀਕੇਸ਼ਨ ਦਾ ਇਨਕਾਰ 401 ਜਾਂ 403 ਵਾਪਸ ਕਰਦਾ ਹੈ। ਤੁਹਾਡੇ ਕੋਲ ਕਿਹੜੀ ਹੈ ਇਹ ਦੇਖਣ ਲਈ ਬੇਨਤੀ ਨੂੰ Requests ਤੋਂ ਬਾਹਰ ਦੁਬਾਰਾ ਚਲਾਓ। ਹੇਠਾਂ ਦਿੱਤੇ ਹੁਕਮ ਪ੍ਰੌਕਸੀ ਹਟਾਉਂਦੇ ਹਨ, ਸਰਟੀਫਿਕੇਟ ਚੇਨ ਪਰਖਦੇ ਹਨ ਅਤੇ ਫਿਰ ਲਾਇਬ੍ਰੇਰੀ ਰਾਹੀਂ ਕਾਲ ਦੁਹਰਾਉਂਦੇ ਹਨ।

curl -sv --noproxy '*' https://api.corp.example/status -o /dev/null
openssl s_client -connect api.corp.example:443 -servername api.corp.example </dev/null
python3 -c "import requests;r=requests.get('https://api.corp.example/status',timeout=10);print(r.status_code)"

ਜੇ curl ਕਾਲ ਸਫਲ ਹੋਵੇ ਅਤੇ Python ਕਾਲ ਅਸਫਲ ਹੋਵੇ, ਤਾਂ ਵੀ ਫਰਕ ਵਾਤਾਵਰਣ ਹੈ। ਜੇ ਦੋਵੇਂ TLS ਪੜਾਅ 'ਤੇ ਅਸਫਲ ਹੋਣ, ਪ੍ਰੌਕਸੀ ਕਦੇ ਸਮੱਸਿਆ ਨਹੀਂ ਸੀ ਅਤੇ ਸਰਟੀਫਿਕੇਟ ਚੇਨ ਸਮੱਸਿਆ ਹੈ। ਜੇ ਦੋਵੇਂ 401 ਵਾਪਸ ਕਰਨ, ਬੇਨਤੀ ਐਪਲੀਕੇਸ਼ਨ ਤੱਕ ਪਹੁੰਚ ਗਈ ਅਤੇ ਬਾਕੀ ਕੰਮ ਪ੍ਰਮਾਣਿਕਤਾ ਹੈ। ਤਿੰਨਾਂ ਵਿੱਚੋਂ ਕਿਹੜੀ ਦੇਖੀ ਇਹ ਦਰਜ ਕਰਨਾ ਅਗਲੇ ਵਿਅਕਤੀ ਦਾ ਇੱਕ ਘੰਟਾ ਬਚਾਉਂਦਾ ਹੈ।

ਵਾਪਸ ਮੁੜਨਾ ਕਿਸੇ ਵੀ ਦਿਸ਼ਾ ਵਿੱਚ ਇੱਕ ਲਾਈਨ ਹੈ: ਬਾਹਰਲਾ ਕਰਨਾ ਹਟਾਓ, ਜਾਂ trust_env ਵਾਪਸ ਪਲਟੋ। ਜੋੜਨ ਤੋਂ ਪਹਿਲਾਂ ਪਿਛਲਾ NO_PROXY ਮੁੱਲ ਸੰਭਾਲੋ, ਅਤੇ ਸਿਰਫ਼ ਤੁਹਾਡੇ ਟਰਮੀਨਲ ਇਤਿਹਾਸ ਵਿੱਚ ਰਹਿਣ ਵਾਲੇ ਐਕਸਪੋਰਟ ਦੀ ਬਜਾਏ ਰੈਪਰ ਸਕ੍ਰਿਪਟ ਜਾਂ ਯੂਨਿਟ-ਪੱਧਰੀ Environment= ਐਂਟਰੀ ਨੂੰ ਤਰਜੀਹ ਦਿਓ। ਦੋਵੇਂ ਬਦਲਾਅ ਪ੍ਰਕਿਰਿਆ ਦੇ ਵਾਤਾਵਰਣ ਵਿੱਚ ਦਿਖਦੇ ਹਨ, ਇਸ ਲਈ ਮੁੜ ਸ਼ੁਰੂ ਕਰਨਾ ਆਮ ਤੌਰ 'ਤੇ ਤੁਹਾਨੂੰ ਪੁਰਾਣੇ ਵਿਵਹਾਰ 'ਤੇ ਵਾਪਸ ਲੈ ਆਉਂਦਾ ਹੈ।

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

ਸੰਬੰਧਿਤ ਲੇਖ