למה curl מתחבר ל-localhost במקום לכתובת ה-URL המרוחקת

אם curl מנסה להתחבר ל-localhost ללא קשר לכתובת ה-URL שנתתם לו, ה-VPN הוא המקום הלא נכון להתחיל בו. ייתכן ש-proxy מקומי מסוג HTTP או SOCKS הוא החיבור הראשון שהתכוונתם אליו, גם כשהשירות שאתם רוצים נמצא במקום אחר לגמרי. אם ה-proxy הזה כבר לא פועל, הניסיון ל-localhost נכשל לפני ש-curl מגיע בכלל ליעד. גם תשובה מה-proxy אינה הוכחה שהיעד ענה.

בצעו את השלבים האלה לפי הסדר ועצרו בשלב הראשון שמשנה את ניסיון החיבור הראשון.

קראו קודם את כללי ה-proxy של curl עצמו

curl קורא משתני proxy ייעודיים לפרוטוקול, כגון https_proxy ו-HTTPS_PROXY, וכן ALL_PROXY כאשר אין ערך ייעודי לפרוטוקול שרלוונטי. בדקו את הסביבה של ה-shell, השירות או המשימה שבאמת מפעילה את curl, ולא זו שבמסוף הנוכחי שלכם. משימת CI, יחידת systemd ו-shell אינטראקטיבי יכולים לרשת שלוש קבוצות שונות. בדיוק הניחוש מתוך ה-shell הנראה לעין הוא מה שגורם לחקירה הזו לבזבז אחר צהריים שלם.

יש חריג אחד שכדאי לזכור. curl מקבל את http_proxy רק באותיות קטנות; הצורה באותיות גדולות HTTP_PROXY מתעלמת ממנה, ולכן אותה סביבה מתנהגת אחרת בכלים אחרים.

קראו את הערכים באופן פרטי, כי כתובת URL של proxy נושאת לעיתים קרובות אישורי גישה.

לאחר מכן בדקו את קובץ התצורה המוגדר כברירת מחדל של curl לאיתור עקיפות של proxy או חיבור, ואמתו איזה קובץ הרצה אתם מריצים בפועל. כינוי shell, פונקציה או סקריפט עוטף יכולים להוסיף אפשרויות שלעולם לא מופיעות בשורת הפקודה שלכם.

השוו שלוש קריאות עם TLS פעיל

השתמשו ביעד אבחון אחד מאושר ובאותו קובץ בינארי בכל שלוש ההרצות.

curl -v https://service.corp.example/status
curl -q -v https://service.corp.example/status
curl -q --proxy '' -v https://service.corp.example/status

-q מדכא את קובץ ה-curlrc המוגדר כברירת מחדל וחייב להיות הפרמטר הראשון בשורה כדי לפעול. הוא אינו מסיר משתני סביבה של proxy, מה שמפתיע את מי שמצפה לכך. הצורה השלישית מוסיפה ערך ריק של --proxy, וכך עוקפת proxy שהסביבה ביקשה רק עבור הקריאה הזו. השוו את ניסיון החיבור הראשון בכל פלט, ולא את קוד המצב הסופי.

פלט מפורט עלול לחשוף כותרות, אסימונים ואישורי גישה של proxy, לכן שמרו אותו מקומית וקראו קטעים לפני שיתוף.

מה כל תוצאה שוללת

אם דילוג על תצורת ברירת המחדל משנה את החיבור, קובץ התצורה הוא המקור. אם השבתה מפורשת של ה-proxy שעבר בירושה משנה אותו, משתנה הסביבה הוא המקור. אם אף אחד מהם לא משנה אותו ו-localhost עדיין מופיע, בדקו עקיפות חיבור בשורת הפקודה, פתרון שמות מארחים וקובץ ההרצה שנבחר. לכל אחד מהם תיקון אחר, ואף אחד מהם אינו שינוי בניתוב.

טעינת ספריות מותאמות או התנהגות רשת מוזרקת היא שכבה מאוחרת יותר, ומשתנה סביבה לבדו אינו הוכחה לכך.

השאירו את החלטת ה-proxy בנפרד מה-VPN

ברגע ש-curl בוחר יעד ישיר, מערכת ההפעלה עדיין מנתבת את החיבור הזה. השבתת proxy של אפליקציה אינה משביתה את המסלול של ה-VPN או את מדיניות הסינון שלו. בצעו השוואות של גישה ישירה רק במקום שבו האבחון הזה מורשה. בדיקה שעוקפת את המדיניות בשקט אינה תוצאה תקפה, היא תקרית.

אם נדרש proxy מקומי, שחזרו את השירות והכתובת שלו במקום למחוק את ההגדרות שלו.

אם רק יעדים פרטיים נבחרים זקוקים לגישה ישירה, הוסיפו חריגה צרה ומאושרת והשאירו את ה-proxy לכל השאר. שמרו את השגיאה הראשונה מהמסלול שנבחר, כי סירוב של localhost, דחיית CONNECT של proxy, כשל תעודה ושגיאת הרשאה מזהים ארבעה שלבים שונים.