ಖಾಸಗಿ API ಯಲ್ಲಿ Requests ProxyError? ಮೊದಲು ಪರಿಸರ ಪರಿಶೀಲಿಸಿ

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 ಯಾವುದಕ್ಕೆ ಪರಿಹರಿಸುತ್ತದೆ ಎಂಬುದನ್ನು ಬದಲಿಸುತ್ತವೆ. ಔಟ್ಪುಟ್ ಖಾಲಿಯಾಗಿದ್ದರೆ ಪರಿಸರ ನಿಮ್ಮ ಸಮಸ್ಯೆ ಅಲ್ಲ ಮತ್ತು ಈ ವಿಭಾಗವನ್ನು ಓದುವುದನ್ನು ನಿಲ್ಲಿಸಬಹುದು. ನೀವು ಗುರುತಿಸದ ಪ್ರಾಕ್ಸಿಯನ್ನು ಅದು ಪಟ್ಟಿ ಮಾಡಿದರೆ, ಏನನ್ನೂ ಬದಲಿಸುವ ಮೊದಲು ಅದನ್ನು ಸೆಟ್ ಮಾಡುವ ಫೈಲ್ ಅಥವಾ ಘಟಕವನ್ನು ಹುಡುಕಿ.

ನಿರ್ದಿಷ್ಟ URL ನೊಂದಿಗೆ Requests ಏನು ಮಾಡುತ್ತದೆ ಎಂದು ಕೇಳಿ. ಈ ಕರೆ ಪ್ಯಾಕೆಟ್ ಕಳುಹಿಸದೆ ಆ ವಿನಂತಿಗೆ ಸೇರಿಸಿದ ಪ್ರಾಕ್ಸಿ, 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 ವಿರುದ್ಧ ಮಾನ್ಯವಾಗುತ್ತದೆ, ವಿನಂತಿ ನೀವು ನಿರೀಕ್ಷಿಸುವ ಸ್ಥಿತಿ ಹಿಂತಿರುಗಿಸುತ್ತದೆ, ಮತ್ತು ಬದಲಾವಣೆ ಮರುಸೃಷ್ಟಿಸಬಹುದಾದ ಸ್ಥಳದಲ್ಲಿ commit ಆಗಿದೆ. ವಿವರಿಸಲಾಗದ ಪರಿಸರದೊಂದಿಗೆ ಹಸಿರು ಸ್ಕ್ರಿಪ್ಟ್ ಮುಂದಿನ ಯಂತ್ರದಲ್ಲಿ ಮತ್ತೆ ಮುರಿಯುವ ತಿದ್ದುಪಡಿ. ಈ ಕೈಪಿಡಿಯ ಆಜ್ಞೆಗಳೇ ಟಿಕೆಟ್ನಲ್ಲಿ ಅಂಟಿಸಬೇಕಾದವು.