איך להגדיר Proxy ב-Axios עבור Node.js (כן, גם ל-HTTPS)

איפשהו ב-Stack Overflow כרגע, מישהו בטוח ש-Axios "נשבר בשקט" עם פרוקסי HTTPS. זו אחת הטענות שחוזרות שוב ושוב במדריכי Node.js proxy, אבל היא לא מתארת את הגרסה העדכנית שנבדקה במדריך הזה. הרמתי סביבת בדיקה מקומית עם מקורות HTTP ו-HTTPS אמיתיים מאחורי שני פרוקסים, ו-Axios 1.19.0 העביר את בקשת ה-HTTPS דרך בקשת CONNECT תקינה במקום לעקוף את הפרוקסי.

זה לא אומר שהבעיות שאנשים מתארים הן דמיוניות. לגרסאות ישנות של Axios היו באגים אמיתיים (ראו את issue #3384 ואת issue #4531), וגרסאות Node חדשות מוסיפות מסלול נוסף של פרוקסי דרך משתני סביבה שדורש הגדרה מדויקת. המדריך הזה מסביר מה באמת עובד ב-Axios 1.19.0 נכון להיום, כל השיטות לחיבור פרוקסי לבקשות שלכם, דפוס רוטציה עם interceptors שכמעט אף מדריך לא מציג, וטבלה מלאה של שגיאות ופתרונות כשדברים בכל זאת משתבשים.

מהו Axios Proxy ולמה הוא בכלל חשוב ב-Node.js?

בהקשר של Axios, פרוקסי הוא פשוט שרת מתווך שיושב בין תהליך ה-Node שלכם לבין האתר היעד. הבקשה שלכם מגיעה קודם לפרוקסי, הפרוקסי מעביר אותה הלאה, והיעד רואה את כתובת ה-IP של הפרוקסי במקום את שלכם. זה כל הטריק.

מפתחים משתמשים בזה מסיבות שונות: סקרייפינג של אתרים שמגבילים קצב או חוסמים לפי IP, בדיקה של התנהגות אפליקציה מאזור גאוגרפי אחר, ניתוב תעבורה דרך שער יציאה ארגוני, או פשוט שמירה על כתובת ה-IP של השרת שלהם מחוץ ללוגים של האתר היעד. תצורת הבקשה הרשמית של Axios כוללת אפשרות מובנית בשם proxy עם השדות host, port, protocol ו-auth — היא קיימת כבר שנים, והיא הדבר הראשון שכל מדריך (כולל זה) מציג.

אבל יש כאן נקודה שמדלגים עליה: אפשרות ה-proxy מתנהגת אחרת כשהיעד הוא HTTP לעומת HTTPS, וגם בהתאם לגרסת Axios שאתם מריצים. ההבחנה הזאת היא בדיוק הסיבה שהמדריך הזה קיים.

הגדרת Node.js ו-Axios (בסיס מהיר)

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

mkdir axios-proxy-demo && cd axios-proxy-demo
npm init -y
npm install axios

הוסיפו "type": "module" ל-package.json אם אתם רוצים להשתמש ב-ESM imports (אני כן — require() של CommonJS בהדגמת פרוקסי מרגיש מיושן). גרסת ה-LTS הנוכחית של Node היא v24.18.0, אבל אני הרצתי את הבדיקות על v22.22.3 כדי שהתוצאות לא יהיו תלויות בגחמות של זמן הריצה החדיש ביותר.

הכניסו את זה ל-app.js והריצו node app.js:

import axios from 'axios';

const res = await axios.get('https://httpbin.org/ip');
console.log(res.data);

אתם אמורים לראות את כתובת ה-IP האמיתית שלכם בתגובה. זהו קו הבסיס שלכם — ברגע שהפרוקסי עובד, אותה בקשה בדיוק אמורה להחזיר במקום זאת את ה-IP של הפרוקסי.

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

האם Axios באמת תומך בפרוקסי HTTPS? בואו ניישר את העובדות

התשובה הקצרה: כן, בגרסה היציבה הנוכחית. Axios 1.19.0 מתעד tunneling באמצעות CONNECT עבור יעדי HTTPS מאחורי פרוקסי HTTP. ב-API של הורדות npm נרשמו 117,890,039 הורדות של Axios בין 31 ביולי ל-6 באוגוסט 2026, אינדיקציה מיושנת אך שימושית עד כמה הספרייה הזו נפוצה. כשניגשים לכתובת HTTPS דרך פרוקסי, Axios הנוכחי שולח בקשת CONNECT כדי ליצור tunnel, ו-Handshake ה-TLS מתבצע מקצה לקצה מול המקור האמיתי. בדקתי זאת ישירות: פרוקסי HTTP מקומי, מקור HTTPS מקומי עם תעודה עצמית, ומונה ה-CONNECT בפרוקסי עלה בדיוק כפי שציפיתי.

אז למה "Axios HTTPS proxy broken" מופיע כמעט בכל שרשור על פרוקסי? יש כמה סיבות, וכולן אמיתיות:

• גרסאות ישנות של Axios. הבעיות שמקשרים אליהן ב-GitHub הן לעיתים בנות שנים ומתארות התנהגות ספציפית לגרסה ולתצורה, שאסור להכליל על Axios הנוכחי.
• שרתי פרוקסי בלי תמיכה ב-CONNECT. בתצורה כזו ה-tunnel נכשל, ו-Axios אמור להחזיר שגיאה; צריך ללכוד את המסלול והשגיאה בפועל לפני שמסיקים שמדובר בעקיפה של IP.
• בלבול בין תצורת proxy לבין משהו אחר. האפשרות proxy היא הוראה לפרוקסי forward, לא מתג כללי של "לנתב הכל דרך הסוכן הזה לא משנה מה".

Chromium דיווח ב-2023 שיותר מ-90% מהניווטים של Chrome בפלטפורמות הגדולות השתמשו ב-HTTPS. זו מדידה מיושנת של Chrome, לא מפקד עדכני של כל האינטרנט, אבל היא מסבירה למה התנהגות מול יעד HTTPS צריכה להיות במרכז המדריך הזה. אם אתם על גרסת Axios ישנה, שחזרו את הבעיה על הקו הנוכחי לפני שאתם מניחים שבעיה היסטורית עדיין מייצגת את ההתנהגות הנוכחית; בדקו את השדרוג באפליקציה שלכם לפני שתפרסו אותו.

מתי עדיין תרצו Agent מפורש

תצורת proxy מובנית מספיקה לפרוקסי יחיד, סטטי וקונבנציונלי. אבל היא מתחילה להישבר ברגע שאתם צריכים שליטה לכל בקשה, רוטציית פרוקסי, או תמיכה ב-SOCKS — האפשרות המובנית של Axios פשוט לא נבנתה לזה. כאן HttpsProxyAgent נכנס לתמונה, ועליו אפרט בהמשך. חשבו על האפשרות המובנית כעל "מספיק טוב עבור פרוקסי אחד ושימוש אחד", ועל הגישה המבוססת על agent כעל "מה שבאמת תרצו בפרודקשן".

מסלול פרוקסי בסביבת Node v24 ו-v22.21+

גרסאות Node חדשות מגיעות עם מצב מובנה של פרוקסי דרך משתני סביבה, שמופעל באמצעות NODE_USE_ENV_PROXY=1 או הדגל --use-env-proxy. לפי תיעוד ה-CLI של Node, זה נכנס ב-v24.0.0 והועבר אחורה ל-v22.21.0 — לכן "Node 22+" הוא ניסוח לא מדויק; זה ספציפית v22.21.0 ומעלה בתוך אותו ענף. אם אתם על patch מוקדם יותר של Node 22, הדגל הזה פשוט לא קיים אצלכם.

Axios הנוכחי כבר פותר את HTTP_PROXY, HTTPS_PROXY ו-NO_PROXY דרך התלות proxy-from-env, כך ש-global-agent לא נדרש למסלול הזה ב-Axios הנוכחי. כשמצב env-proxy המובנה של Node פעיל גם כן, עשויות להיות שתי שכבות שמעורבות בהחלטה על הניתוב.

התיעוד של Axios מציין שבגרסאות Node שבהן ל-agent יש מאפיין proxyEnv, Axios מעביר את הטיפול ל-Node במקום לפתור זאת בעצמו. בפועל, זה אומר שכדאי לבחור מערכת אחת ולהיצמד אליה:

• לתת ל-Node לנהל זאת: להפעיל את הדגל, לא להגדיר את proxy ב-Axios, ולתת למשתני הסביבה לעשות את העבודה.
• לתת ל-Axios לנהל זאת: לא להפעיל את דגל Node, ולתת לפתרון משתני הסביבה של Axios לפעול.
• שליטה ידנית מלאה: להגדיר במפורש proxy: false ולספק httpsAgent משלכם — כך עוקפים לחלוטין את שתי המערכות האוטומטיות, וזה מה שאני ממליץ ברגע שצריך רוטציה או לוגיקה לכל בקשה.

בדקתי את פתרון הצד של Axios ישירות: הגדרת HTTP_PROXY בסביבה של תהליך child ניתבה את הבקשה דרך הפרוקסי המקומי שלי, והוספת ערך תואם ב-NO_PROXY גרמה לבקשה הבאה לדלג עליו כראוי. כלומר, מסלול משתני הסביבה באמת עובד כברירת מחדל עכשיו — אבל את מצב הפעולה הכפול צריך לשים לב אליו.

5 דרכים לחבר פרוקסי ל-Axios (בהשוואה)

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

שיטה	תמיכה ב-HTTPS	תמיכה באימות	שליטה לכל בקשה	מתאימה לרוטציה	מורכבות
אפשרות proxy בתוך הבקשה	✅ (ב-Axios הנוכחי)	✅	✅	❌	נמוכה
ברירות מחדל של axios.create()	✅ (ב-Axios הנוכחי)	✅	❌ (ברמת ה-instance)	❌	נמוכה
משתני סביבה (HTTP_PROXY/HTTPS_PROXY)	✅	✅	❌	❌	נמוכה
httpsAgent + HttpsProxyAgent	✅	✅	✅	⚠️ (ידני)	בינונית
interceptor לבקשה + מאגר agents	✅	✅	✅	✅	בינונית-גבוהה

השתמשו באפשרות המובנית אם אתם צריכים סקריפט מהיר שמדבר עם פרוקסי אחד. השתמשו ב-axios.create() כשכל בקשה במודול מסוים צריכה לעבור דרך אותו פרוקסי בלי לחזור על התצורה. השתמשו במשתני סביבה כשהצוות התשתיתי כבר מנהל את ניתוב הפרוקסי באופן מרכזי ואתם רוצים פשוט לרשת אותו. עברו ל-agent מפורש כשאתם צריכים שליטה שהתצורה המובנית לא נותנת — ועברו לדפוס של interceptor ברגע ש"שליטה" הופכת ל"רוטציה".

שלב אחר שלב: הגדרת Proxy בסיסית ב-Axios

ההגדרה הפשוטה ביותר משתמשת ישירות באובייקט proxy המובנה בבקשה:

import axios from 'axios';

const res = await axios.get('https://httpbin.org/ip', {
  proxy: {
    host: '203.0.113.10',
    port: 8080,
    protocol: 'http',
  },
});

console.log(res.data);

הריצו את זה ותראו בתגובה את ה-IP של הפרוקסי במקום את שלכם. אם אתם בודקים מקומית עם פרוקסי אמיתי, זה בדרך כלל נפתר בפחות משנייה — לעומת למשל הגדרה ידנית של פרוקסי ברמת המערכת רק כדי לבדוק בקשה אחת, שזה מסוג הדברים שגוזלים רבע שעה שאין לכם.

השוו את התגובה הזו לקו הבסיס. בדיקה מוצלחת אמורה להציג את ה-IP הציבורי של הפרוקסי במקום כתובת המקור שרשמתם קודם.

שימוש ב-axios.create() כברירות מחדל לכל ה-instance

אם כל בקשה במודול מסוים צריכה לעבור דרך אותו פרוקסי, כדאי להכניס זאת ל-instance במקום לחזור על אותה תצורה שוב ושוב:

const client = axios.create({
  proxy: {
    host: '203.0.113.10',
    port: 8080,
  },
  timeout: 15_000,
});

const res = await client.get('https://httpbin.org/ip');

אימתתי ש-proxy: false בבקשה בודדת עוקף בצורה נקייה את ברירת המחדל של ה-instance — שימושי אם 95% מהקריאות שלכם צריכות פרוקסי אבל כמה בודדות (למשל ping של health-check) לא.

הגדרת Proxy דרך משתני סביבה

לניתוב מנוהל מרכזית — חשבו על קונטיינרי Docker או סביבות CI שבהן צוות התפעול כבר מגדיר משתני סביבה של פרוקסי — לא צריך לגעת בכלל בתצורת Axios:

export HTTP_PROXY=http://203.0.113.10:8080
export HTTPS_PROXY=http://203.0.113.10:8080
export NO_PROXY=localhost,127.0.0.1

Axios הנוכחי קורא את המשתנים האלה בלי global-agent. רק זכרו את גבול הגרסה של Node שצוין למעלה: אם NODE_USE_ENV_PROXY פעיל גם הוא, הגדירו במפורש מי הבעלים של הניתוב ובדקו את התנהגות NO_PROXY בזמן הריצה שבו תפרסו.

שלב אחר שלב: הגדרת פרוקסי HTTPS עם httpsAgent (לשליטה אמיתית)

זו ההגדרה שהייתי ממליץ עליה בפועל ברגע שאתם צריכים יותר מ"פרוקסי אחד, לנצח". התקינו את חבילת ה-agent העדכנית:

npm install https-proxy-agent

https-proxy-agent 9.1.0 דורש Node 20 ומעלה ושולח בקשת CONNECT תקינה אל הפרוקסי לפני שהוא מעביר דרכו את חיבור היעד.

import axios from 'axios';
import { HttpsProxyAgent } from 'https-proxy-agent';

const agent = new HttpsProxyAgent('http://203.0.113.10:8080');

const client = axios.create({
  proxy: false,        // מונע מ-Axios מהלוגיקה המובנית שלו להתערב גם היא
  httpsAgent: agent,
  timeout: 15_000,
});

const res = await client.get('https://httpbin.org/ip');
console.log(res.data);

הגדירו proxy: false כשה-agent המפורש הוא זה ששולט בניתוב. כך התצורה ברורה ולא משתמעת לשני פנים, ומונעת מ-Axios או מהתמיכה בפרוקסי דרך משתני הסביבה להתחרות ב-agent שסיפקתם.

הוספת אימות לפרוקסי

מכניסים את פרטי ההתחברות ישירות ל-URL של הפרוקסי:

const agent = new HttpsProxyAgent('http://myuser:mypassword@203.0.113.10:8080');

אם הסיסמה שלכם כוללת תווים מיוחדים — @, :, # הם החשודים הרגילים — קודדו אותם ב-percent-encoding לפני בניית ה-URL, או בנו את המחרוזת עם encodeURIComponent() לכל רכיב. @ גולמי בסיסמה ייקרא כהתחלת החלק של ה-host, ותקבלו שגיאת חיבור שלא קשורה בכלל לקידוד באופן מובן לעין.

שימוש בפרוקסי SOCKS5 עם Axios

פרוקסי SOCKS לא תואם ל-HttpsProxyAgent — בשביל הפרוטוקול הזה צריך agent אחר:

npm install socks-proxy-agent

import { SocksProxyAgent } from 'socks-proxy-agent';

const agent = new SocksProxyAgent('socks5://myuser:mypass@203.0.113.10:1080');

const client = axios.create({
  proxy: false,
  httpsAgent: agent,
});

socks-proxy-agent 10.1.0 גם הוא דורש Node 20 ומעלה. SOCKS5 שווה שימוש כשעובדים מול רשתות ארגוניות שחושפות רק שער SOCKS, או מול ספקי פרוקסי שמציעים תמיכה גמישה יותר בפרוטוקולים מאשר פרוקסי HTTP רגילים.

רוטציית פרוקסים עם Axios באמצעות Request Interceptors

בחירת פרוקסי אקראי בתוך הקוד שקורא לפונקציה עובדת יפה לסקריפט חד-פעמי. היא קורסת ברגע שמגיעים למאות בקשות, כי אין מקום מרכזי שעוקב אחרי הפרוקסים המתים, אין לוגיקת retry, וקוד בחירת הפרוקסי מתפזר והופך להעתקה-הדבקה בכל מקום. מערכת ה-interceptors של Axios נותנת ללוגיקה הזו בית אחד שאפשר לבדוק; אף אחד מחמשת המדריכים המתחרים שבדקתי ב-SERP לא השתמש בדפוס הזה.

בניית Proxy Pool

import axios, { AxiosError, InternalAxiosRequestConfig } from 'axios';
import { HttpsProxyAgent } from 'https-proxy-agent';

class ProxyPool {
  private agents: HttpsProxyAgent<string>[];
  private index = 0;

  constructor(proxyUrls: string[]) {
    this.agents = proxyUrls.map((url) => new HttpsProxyAgent(url));
  }

  next(): HttpsProxyAgent<string> {
    const agent = this.agents[this.index];
    this.index = (this.index + 1) % this.agents.length;
    return agent;
  }
}

const pool = new ProxyPool([
  'http://user:pass@proxy1.example.com:8080',
  'http://user:pass@proxy2.example.com:8080',
]);

const client = axios.create({ timeout: 15_000 });

client.interceptors.request.use((config: InternalAxiosRequestConfig) => {
  config.proxy = false;
  config.httpsAgent = pool.next();
  return config;
});

הרצתי את זה מול שני פרוקסים מקומיים ואישרתי שהבקשות מתחלפות כמו שצריך — פרוקסי A, ואז B, ואז שוב A. שימו לב ש-Axios מריץ request interceptors בסדר הפוך להוספה (last-in-first-out), אז אם יש לכם עוד interceptors (כמו כותרות auth או לוגינג), הסדר חשוב יותר ממה שנדמה.

הוספת Response Interceptor עם מגבלת Retry

כאן רוב הסקריפטים הביתיים לרוטציה מתחילים להיות רשלניים. ניסיון חוזר עיוור על כל כשל, מול מאגר בלתי מוגבל, יכול להפוך בקשה אחת שנכשלת לבלגן מתגלגל — במיוחד עבור מתודות לא-idempotent כמו POST, שבהן retry עלול לשכפל פעולה צדדית שלא רציתם לשכפל.

type RetryableConfig = InternalAxiosRequestConfig & {
  __proxyRetryCount?: number;
};

client.interceptors.response.use(
  undefined,
  async (error: AxiosError) => {
    const config = error.config as RetryableConfig | undefined;
    if (!config) throw error;

    const method = String(config.method ?? 'get').toUpperCase();
    config.__proxyRetryCount ??= 0;
    if (method !== 'GET' || config.__proxyRetryCount >= 1) throw error;

    config.__proxyRetryCount += 1;
    config.proxy = false;
    config.httpsAgent = pool.next();
    return client.request(config);
  }
);

בדקתי את זה מול פרוקסי שבור בכוונה ואישרתי שניסיון חוזר אחד בלבד יצא לדרך על agent חלופי — בלי לולאה אינסופית, בלי retry על בקשת POST. זה הגבול שאתם רוצים: מדיניות retry שמודה אילו בקשות בטוח לשחזר, ולא פריצה של "פשוט ננסה שוב עד שיעבוד".

טבלת אבחון שגיאות: מיפוי כל כשל לפתרון שלו

שמרו את זה. אלו השגיאות שבאמת מופיעות ב-Issues של Axios ובשרשורי Stack Overflow, לא תיאורטיות.

שגיאה / סימפטום	סיבה סבירה	פתרון
ECONNREFUSED	host/port שגויים, או ששרת הפרוקסי לא פעיל	בדקו עם curl -x http://host:port target-url לפני שנוגעים בקוד של Axios
407 Proxy Authentication Required	פרטי התחברות חסרים או שגויים	הוסיפו auth: { username, password } לתצורת proxy, או הטמיעו את פרטי ההתחברות ב-URL של HttpsProxyAgent
403 Forbidden	המקור או WAF דחו את הבקשה או את IP של הפרוקסי	בדקו את מדיניות הגישה של האתר, את האימות, ואת קצב הבקשות; אל תתייחסו לכותרת אחרת או ל-IP אחר כהיתר לעקיפת מגבלות
התגובה מציגה את ה-IP האמיתי שלכם	ייתכן ש-NO_PROXY, proxy:false, agent ישיר מפורש, או תצורה ישנה/תלוית גרסה עוקפים את הפרוקסי	בדקו מי שולט בניתוב; אמתו את המסלול עם endpoint ייעודי ל-IP ו-agent מפורש אם צריך
ETIMEDOUT	זמן החיבור או זמן התגובה עברו את ה-timeout שהוגדר	מדדו היכן הזמן נצרך; שנו את ה-timeout רק אם עומס העבודה מצדיק זאת, אחרת החליפו או קררו את הנתיב הבעייתי
ECONNRESET באמצע התגובה	הפרוקסי, הרשת או המקור סגרו את החיבור	רשמו באיזה hop הכשל קורה; בצעו retry רק לבקשות שניתן לשחזר ובתקציב ניסיונות סופי
502 Bad Gateway מאחורי Nginx	proxy_pass של Nginx מוגדר לא נכון, או ש-timeout של Axios לא תואם ל-Nginx	בדקו את proxy_connect_timeout ו-proxy_read_timeout (שניהם ברירת מחדל של 60 שניות) ויישרו אותם מול timeout של Axios
ERR_TLS_CERT_ALTNAME_INVALID	agent לא מתאים ליעד, או תעודה עצמית	ודאו שאתם משתמשים ב-agent הנכון לפרוטוקול; הגדירו rejectUnauthorized: false רק לבדיקות מקומיות — לא בפרודקשן

צ'ק-ליסט מהיר לדיבוג

כשמשהו נשבר ואתם לא מבינים למה, עברו על זה לפי הסדר:

1. בדקו את הפרוקסי ישירות עם curl -x http://host:port https://your-target.com. אם זה נכשל, בדקו חיבוריות לפרוקסי, אימות, והיעד לפני שמשנים את Axios. אם זה מצליח, עדיין צריך לאמת בנפרד את המסלול של Axios.
2. ודאו אילו גרסאות Axios ו-Node אתם באמת מריצים, והשוו דיווחים היסטוריים עם אותה גרסה/תצורה לפני שמיישמים את הפתרונות שלהם.
3. בררו איזו מערכת פותרת את הפרוקסי — תצורת Axios מובנית, פתרון משתני סביבה של Axios, מצב env-proxy המובנה של Node, או agent מפורש. אל תתנו ליותר ממערכת אחת לשלוט באותה בקשה.
4. בדקו את NO_PROXY כדי לזהות התאמות לא מכוונות לשמות host.
5. אם אתם משתמשים ב-agent מפורש, ודאו ש-proxy: false מוגדר כדי ש-Axios לא ינסה לטפל בזה פעמיים.

מתי לדלג לגמרי על כל תשתית ה-Proxy הזו

כל מה שהוצג כאן באמת שימושי אם המטרה שלכם היא ניתוב תעבורה כלשהי — בדיקות רשת ארגונית, בדיקות גאוגרפיות של אפליקציה, או יציאה מבוקרת לרשת. אבל הרבה מפתחים מגיעים ל"איך מגדירים Axios proxy" כי מה שהם באמת רוצים זה נתונים מאתר, והפרוקסי הוא רק אמצעי בדרך.

אם זה המצב שלכם, שווה לשאול האם אתם בכלל צריכים פרוקסי, או שאולי אתם צריכים API לסקרייפינג שמטפל בתשתית בשבילכם. ה-Open API של Thunderbit מקבל URL ו-schema ומחזיר JSON מובנה — בלי ניתוח HTML גולמי, בלי ספריות agents, ובלי מאגר פרוקסים שצריך לתחזק. נקודת הקצה /extract מטפלת בשרת בדפים שנרנדרו ב-JS, באמצעי אנטי-בוט, וב-CAPTCHAs, ויש גם נקודת קצה קלה יותר /distill שממירה דף ל-Markdown נקי אם זה כל מה שאתם צריכים. יש גם MCP server שחושף כלים כמו thunderbit_extract ו-thunderbit_suggest_fields, כך שעוזרי קוד כמו Claude או Cursor יכולים לשלוף נתונים מובנים תוך כדי עבודה בלי לגעת בכלל בתצורת פרוקסי, וגם CLI לזרימות עבודה בטרמינל וב-CI.

סוגיה	DIY עם Axios + פרוקסים	Thunderbit API/MCP/CLI
מקור פרוקסי ורוטציה	אתם מנהלים	מטופל בצד השרת
אתגרי דפדפן וגישה	אתם מפעילים את שכבת הדפדפן/רשת	מנוהל על ידי השירות במסגרת היכולות המתועדות שלו
דפים שנרנדרו ב-JS	צריך דפדפן headless	renderMode: full
פורמט פלט	HTML גולמי → אתם מנתחים	JSON מובנה לפי schema
תחזוקה כשהאתרים משתנים	אתם מתחזקים את ה-parsing/selectors	שכבת החילוץ המנוהלת מפחיתה חלק מעבודת התחזוקה בצד האפליקציה

הניסוח הכנה הוא כזה: אם אתם צריכים לנתב תעבורה לצורכי בדיקה או רשת ארגונית, שום דבר כאן לא מחליף את Axios ותצורת פרוקסי. אם התוצר שלכם הוא נתוני ווב מובנים, גישת API-first עשויה להפחית את כמות קוד הפרוקסי, הדפדפן וה-parsing שבאחריות האפליקציה שלכם. בעת השליפה ב-7 באוגוסט 2026, תיעוד מגבלות הקצב של Thunderbit הציג את שכבת Free עם 10 בקשות בדקה ו-2 בקשות מקבילות. התייחסו אליהן כמגבלות API תלויות זמן ובדקו שוב את הדף לפני שאתם סומכים עליהן בפרודקשן.

לסיכום

השורה התחתונה כאן נוגדת את מה שמדריכים ישנים רבים אומרים: Axios הנוכחי מתעד, ובבדיקה המקומית גם השתמש נכון, ב-CONNECT tunneling עבור יעד HTTPS. תקלות היסטוריות עדיין חשובות, אבל הן חייבות הקשר של גרסה ותצורה. תצורה מובנית היא נקודת פתיחה טובה ופשוטה; כשצריך שליטה לכל בקשה, תמיכה ב-SOCKS או רוטציה, HttpsProxyAgent (או SocksProxyAgent) מפורש יחד עם proxy: false נותן לכם בעלות ברורה יותר. ואם אתם מבצעים רוטציה על פני מאגר בפרודקשן, request ו-response interceptors נותנים מקום מרכזי וניתן לבדיקה לעשות זאת — רק ודאו שלוגיקת ה-retry שלכם מוגנת מלולאות, ורק משחזרת בקשות שבאמת בטוח לשחזר.

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

שאלות נפוצות

האם Axios תומך בפרוקסי HTTPS באופן מובנה? כן, ב-Axios הנוכחי עבור פרוקסי HTTP קונבנציונלי: התיעוד הנוכחי מתאר CONNECT tunneling עבור יעדי HTTPS, ו-Axios 1.19.0 עבר את הנתיב הזה בבדיקה המקומית שתועדה. גרסאות היסטוריות ותצורות פרוקסי מסוימות יצרו תקלות אמיתיות, לכן חשוב לאמת את הגרסה והפרוקסי הספציפיים ולא להניח הצלחה או כישלון מוחלטים.

איך עושים רוטציה לפרוקסים ב-Axios? השתמשו ב-request interceptor כדי להקצות httpsAgent אחר מתוך מאגר פרוקסים לפני כל שליחת בקשה, ובשילוב response interceptor שמנסה שוב בקשות שנכשלו דרך פרוקסי אחר. שמרו את מדיניות ה-retry מוגבלת — ניסיון חוזר אחד, ורק למתודות idempotent כמו GET — כדי לא לשחזר בטעות בקשה שאסור לשחזר.

למה הפרוקסי שלי ב-Axios מציג את ה-IP האמיתי שלי? בדקו אם NO_PROXY, proxy:false, agent ישיר מפורש, או ניתוב ייחודי לסביבת הפריסה עוקפים את הפרוקסי. רשמו את גרסאות Axios/Node ובדקו את הפרוקסי בנפרד עם cURL. אם אתם צריכים ניתוב חד-משמעי לכל בקשה, השתמשו ב-HttpsProxyAgent עם proxy:false ואמתו את ה-IP הנצפה endpoint מבוקר.

אפשר להשתמש ב-SOCKS5 proxies עם Axios? כן, דרך החבילה socks-proxy-agent. צרו מופע SocksProxyAgent עם כתובת ה-SOCKS שלכם והעבירו אותו כ-httpsAgent בתצורת Axios — רק ודאו שאינכם מעבירים גם HttpsProxyAgent, כי שני הפרוטוקולים משתמשים בסוגי agent שונים.

מה ההבדל בין אפשרות proxy לבין httpsAgent ב-Axios? אפשרות proxy היא התצורה המובנית של Axios לפרוקסי יחיד וסטטי, והיא מתאימה היטב לתרחישים פשוטים בגרסאות הנוכחיות. httpsAgent מקבל agent מותאם של Node.js — כמו HttpsProxyAgent או SocksProxyAgent — ונותן לכם שליטה ישירה, לכל בקשה, על ניתוב, אימות ורוטציה, משהו שהאפשרות המובנית לא נועדה לטפל בו.

למידע נוסף

• מהו Web Scraping
• AI Web Scraping
• חלופות ל-Instant Data Scraper
• סקרייפינג ל-LinkedIn
• Web Scraping בלי קוד