كيفية إعداد Proxy في Axios لـ Node.js (نعم، حتى HTTPS)

في مكان ما على Stack Overflow الآن، في ناس لسه مقتنعة إن Axios “يعلّق بصمت” لما تستخدم HTTPS proxies. هذي من أكثر الادعاءات تكرارًا في شروحات Node.js الخاصة بالـ proxy، لكنها ما تعكس النسخة الحالية اللي اختبرتها لهالمقال. سويت بيئة اختبار محلية فيها مصادر HTTP وHTTPS حقيقية خلف بروكسيين مختلفين، ونجح Axios 1.19.0 في تمرير طلب HTTPS عبر طلب CONNECT صحيح بدل ما يلفّ على البروكسي.

هذا ما يعني إن المشاكل اللي يتكلم عنها الناس وهمية. الإصدارات القديمة من Axios كان فيها أخطاء فعلية فعلًا (راجع issue #3384 وissue #4531 للتفاصيل)، وكمان إصدارات Node الحديثة تضيف مسار ثاني لاستخدام بروكسيات البيئة يحتاج ضبط دقيق. هذا الدليل يشرح وش اللي يشتغل فعلًا في Axios 1.19.0 إلى اليوم، وكل الطرق الممكنة لربط الـ proxy بطلباتك، ونمط تدوير البروكسيات باستخدام interceptors اللي تقريبًا ما تذكره أي مقالة ثانية، بالإضافة إلى جدول كامل يحوّل الأخطاء إلى حلول لما الأمور تتعطل.

ما هو Axios Proxy ولماذا يهم في Node.js؟

الـ proxy في سياق 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 إذا تبغى تستخدم imports بنمط ESM (وأنا أفضل هذا — استخدام CommonJS مع require() في مثال عن proxy يبان قديم). أحدث Node LTS هو v24.18.0، لكني سويت اختباراتي على v22.22.3 تحديدًا حتى ما تعتمد النتائج على سلوكيات جديدة خاصة بأحدث runtime.

حط هذا في 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 استخدام CONNECT tunneling مع أهداف HTTPS خلف بروكسي HTTP. وسجّل API التنزيلات في npm عدد 117,890,039 تنزيلًا لـ Axios بين 31 يوليو و6 أغسطس 2026، وهو مؤشر قديم نسبيًا لكنه يوضح قد إيش المكتبة منتشرة. لما تضرب عنوان HTTPS عبر بروكسي، يرسل Axios الحالي طلب CONNECT لإنشاء نفق، وبعدها تتم مصافحة TLS من البداية للنهاية مع الأصل الحقيقي. اختبرت هذا بنفسي: بروكسي HTTP محلي، وأصل HTTPS محلي بشهادة self-signed، وعدّاد CONNECT في البروكسي ارتفع بالضبط كما ينبغي.

طيب ليه تظهر عبارة "Axios HTTPS proxy broken" في كل نقاش تقريبًا على المنتديات؟ فيه أكثر من سبب، وكلها حقيقية:

• إصدارات Axios القديمة. المشاكل اللي يربطها الناس غالبًا ترجع لسنوات ماضية، وتصف سلوك خاص بإصدار أو إعداد معين، وما يصح نعممها على Axios الحالي.
• خوادم proxy ما تدعم CONNECT. في هذي الحالة يفشل النفق، ولازم يظهر Axios خطأ واضح؛ التقط المسار الفعلي ورسالة الخطأ قبل ما تحكم إن البروكسي تم تجاوزه.
• الخلط بين إعداد proxy وبين شيء ثاني. خيار proxy هو توجيه عبر forward proxy، وليس زر عام بمعنى "مرّر كل شيء عبر هذا الـ agent مهما كان".

أفاد Chromium في 2023 أن أكثر من 90% من عمليات التصفح في Chrome عبر المنصات الرئيسية كانت تستخدم HTTPS. هذا قياس قديم خاص بـ Chrome، وليس إحصاء شامل للويب كله، لكنه يوضح ليه سلوك HTTPS-target لازم يكون في قلب هذا الشرح. إذا كنت على إصدار قديم من 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 في بيئة process فرعي وجّه الطلب عبر بروكسيي المحلي، ثم إضافة NO_PROXY مطابق خلّت الطلب التالي يتجاوزه بشكل صحيح. يعني مسار متغيرات البيئة يشتغل الآن من الصندوق كما ينبغي — لكن لازم تنتبه لموضوع وجود وضعين في نفس الوقت.

5 طرق لربط Proxy في Axios (مقارنة)

قبل ندخل في الكود، هذه الصورة العامة. بنيت كل هذي الأساليب واختبرتها على إعداد بروكسي محلي حقيقي، مو اعتمادًا على قراءة التوثيق فقط.

الطريقة	دعم HTTPS	دعم المصادقة	تحكم لكل طلب	مناسب للتدوير	التعقيد
خيار proxy المضمّن	✅ (في Axios الحالي)	✅	✅	❌	منخفض
الإعدادات الافتراضية عبر axios.create()	✅ (في Axios الحالي)	✅	❌ (على مستوى instance)	❌	منخفض
متغيرات البيئة (HTTP_PROXY/HTTPS_PROXY)	✅	✅	❌	❌	منخفض
httpsAgent مع HttpsProxyAgent	✅	✅	✅	⚠️ (يدوي)	متوسط
request interceptor + agent pool	✅	✅	✅	✅	متوسط-مرتفع

استخدم الخيار المدمج إذا كنت تكتب سكربت سريع يتصل ببروكسي واحد. استخدم axios.create() إذا لازم كل طلبات module معيّن تمر عبر البروكسي نفسه بدون تكرار الإعدادات. استخدم متغيرات البيئة إذا كانت البنية التحتية عندك تدير التوجيه مركزيًا، وأنت بس تبغى ترثه. وانتقل إلى 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 الخاص بالبروكسي في النتيجة بدل عنوانك. إذا كنت تختبر محليًا مع بروكسي حقيقي، عادةً هذا يخلص في أقل من ثانية — مقارنة مثلًا بضبط proxy على مستوى النظام بس عشان تجرب طلب واحد، وهذا النوع من الأشياء يضيّع منك ربع ساعة بلا داعٍ.

قارن هذه النتيجة بخط الأساس. الاختبار الناجح لازم يظهر العنوان العام للبروكسي بدل عنوان الأصل اللي سجلته سابقًا.

استخدام axios.create() لتطبيق الإعدادات على مستوى instance

إذا كان لازم كل الطلبات داخل module واحد تمر عبر نفس البروكسي، الأفضل تحطه داخل 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 لفحص الصحة) ما تحتاجه.

ضبط 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 في runtime الفعلي عند النشر.

خطوة بخطوة: إعداد HTTPS Proxy باستخدام 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 التلقائية أو آلية env-proxy من إنها تتنافس مع الـ agent اللي وفّرته.

إضافة مصادقة للبروكسي

حط بيانات الاعتماد مباشرة داخل رابط البروكسي:

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

إذا كانت كلمة المرور فيها رموز خاصة — مثل @ و: و# وهي أكثر شيء يسبب مشاكل — فقم بترميزها بنظام percent-encoding قبل بناء الرابط، أو أنشئ السلسلة باستخدام encodeURIComponent() لكل جزء. وجود @ خام داخل كلمة المرور راح يُفسَّر كبداية لجزء المضيف، وبتطلع لك مشكلة اتصال ما تبان للوهلة الأولى مرتبطة بالترميز.

استخدام SOCKS5 Proxies مع 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

اختيار بروكسي عشوائي داخل كود الاستدعاء ينفع في سكربت لمرة واحدة. لكنه ينهار لما تسوي مئات الطلبات، لأنه ما فيه نقطة مركزية تتبع البروكسيات المعطلة، ولا منطق لإعادة المحاولة، وينتهي بك الأمر تنسخ منطق اختيار البروكسي بكل مكان. نظام Axios interceptors يعطي هذا المنطق بيت واحد قابل للاختبار؛ وأيًا من الشروحات الخمسة المنافسة اللي راجعتها في نتائج البحث ما استخدمت هالنمط.

بناء 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 ثانية (مثل headers للمصادقة أو logging)، فترتيبها أهم مما تتوقع.

إضافة Response Interceptor مع ضوابط إعادة المحاولة

هنا تبدأ أغلب سكربتات التدوير المكتوبة يدويًا تتلخبط. إعادة المحاولة بشكل أعمى عند كل خطأ، مع pool غير محدود، ممكن يحول طلب واحد فاشل إلى سلسلة من المشاكل المتتابعة — خصوصًا مع الطرق غير idempotent مثل POST، لأن إعادة المحاولة قد تكرر أثر جانبي ما كنت تبيه أصلًا.

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 البديل — لا حلقة لا نهائية، ولا إعادة محاولة على طلب POST. هذا هو الحد اللي تبيه: سياسة إعادة محاولة واضحة للطلبات الآمنة لإعادة الإرسال، مو مجرد "جرّب مرة ثانية لين يضبط".

جدول تشخيص الأخطاء: اربط كل فشل بحلّه

خله عندك كمرجع. هذه هي الأخطاء اللي تطلع فعلًا في GitHub issues الخاصة بـ Axios وفي نقاشات Stack Overflow، مو الأخطاء الافتراضية.

الخطأ / العَرَض	السبب المحتمل	الحل
ECONNREFUSED	خطأ في host/port، أو خادم البروكسي متوقف	تحقق باستخدام curl -x http://host:port target-url قبل ما تعدل كود Axios
407 Proxy Authentication Required	بيانات اعتماد مفقودة أو غير صحيحة	أضف auth: { username, password } إلى إعداد proxy، أو حط بيانات الاعتماد داخل رابط HttpsProxyAgent
403 Forbidden	الأصل أو WAF رفض الطلب أو عنوان IP الخاص بالبروكسي	افحص سياسة الوصول للموقع والمصادقة ومعدل الطلبات؛ لا تفترض إن اختلاف الـ header أو IP يعطيك حق تجاوز القيود
النتيجة تُظهر عنوان IP الحقيقي	ممكن يكون NO_PROXY أو proxy:false أو agent مباشر صريح، أو إعداد قديم/مرتبط بإصدار معين يتجاوز البروكسي	حدّد أي طبقة تملك التوجيه؛ وتحقق من المسار عبر endpoint يتحكم به عنوان IP معروف، ومع agent صريح عند الحاجة
ETIMEDOUT	تجاوزت مهلة الاتصال أو الاستجابة القيمة المضبوطة	قِس أين يضيع الوقت؛ لا تغيّر المهلة إلا إذا طبيعة العمل تبرر ذلك، وإلا فاستبدل المسار غير الصحي أو أعطه فترة تهدئة
ECONNRESET في منتصف الاستجابة	البروكسي أو الشبكة أو الأصل أغلق الاتصال	سجّل القفزة اللي فشلت؛ وأعد المحاولة فقط للطلبات الآمنة للإعادة مع حد نهائي
502 Bad Gateway خلف Nginx	إعداد proxy_pass في Nginx غير صحيح، أو مهلة Axios ما تتوافق مع Nginx	افحص proxy_connect_timeout وproxy_read_timeout (كلاهما افتراضيًا 60 ثانية) وطابقهما مع timeout في Axios
ERR_TLS_CERT_ALTNAME_INVALID	نوع agent غير مناسب للهدف، أو الشهادة self-signed	تأكد من استخدام 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 للتأكد من عدم وجود تطابق غير مقصود في أسماء المضيفين.
5. إذا كنت تستخدم agent صريح، فتأكد من ضبط proxy: false حتى ما يحاول Axios التعامل معه مرتين.

متى تتجاوز إعدادات البروكسي اليدوية تمامًا

كل اللي فوق مفيد فعلًا إذا كان هدفك توجيه حركة مرور عشوائية — مثل اختبار شبكات الشركات، أو اختبار الموقع من مناطق جغرافية مختلفة، أو الخروج عبر شبكة محددة. لكن كثير من المطورين يوصلون لسؤال "كيف أضبط Axios proxy؟" بينما اللي يبغونه في الحقيقة هو بيانات من موقع، والبروكسي مجرد وسيلة للوصول لها.

إذا كان هذا هو وضعك، فمن المفيد تسأل نفسك: هل تحتاج فعلًا إلى بروكسي، أم تحتاج إلى scraping API يتولى البنية التحتية عنك؟ إن Open API الخاص بـ Thunderbit يأخذ عنوان URL ومخطط (schema) ويرجع JSON منظم — بلا تحليل HTML الخام، ولا مكتبات agents، ولا pool بروكسيات تحتاج مراقبة. نقطة النهاية /extract تتعامل مع الصفحات المعروضة عبر JavaScript، وآليات anti-bot، وCAPTCHAs من جهة الخادم، وهناك أيضًا نقطة نهاية أخف /distill تحول الصفحة إلى Markdown نظيف إذا كان هذا كل اللي تحتاجه. ويوجد أيضًا MCP server يوفر أدوات مثل thunderbit_extract وthunderbit_suggest_fields، بحيث تقدر أدوات المساعدة البرمجية مثل Claude أو Cursor تجلب بيانات منظمة أثناء العمل بدون لمس إعداد proxy أصلًا، بالإضافة إلى CLI لاستخدامات الطرفية وCI.

الجانب	DIY Axios + Proxies	Thunderbit API/MCP/CLI
مصدر البروكسي وتدويره	أنت تديره	يُدار على جهة الخادم
تحديات المتصفح والوصول	أنت تدير طبقة المتصفح/الشبكة	تتولى الخدمة ذلك ضمن حدودها الموثقة
الصفحات المعروضة عبر JavaScript	تحتاج إلى متصفح headless	renderMode: full
تنسيق الإخراج	HTML خام → أنت تحلله	JSON منظم عبر schema
الصيانة عند تغيّر المواقع	أنت تتولى التحديث	طبقة الاستخراج المُدارة تقلل بعض أعباء الصيانة على مستوى التطبيق

الصياغة المنصفة هنا: إذا كنت تحتاج إلى توجيه الحركة لأغراض الاختبار أو شبكات الشركات، فما فيه شيء هنا يستبدل Axios وإعداد proxy. أما إذا كان هدفك النهائي هو بيانات ويب منظمة، فاعتماد نهج API-first قد يقلل كثير من كود البروكسي والمتصفح والتحليل اللي يملكه تطبيقك. عند وقت الاسترجاع في 7 أغسطس 2026، كانت وثائق تحديد المعدل في Thunderbit API تعرض خطة Free عند 10 طلبات في الدقيقة وطلبين متزامنين. تعامل مع هذي القيم كحدود API حساسة للوقت، وأعد التحقق من الصفحة قبل الاعتماد عليها في الإنتاج.

الخلاصة

الدرس الأساسي هنا يعاكس كثير من الشروحات القديمة: Axios الحالي يوثّق ويستخدم في الاختبار المحلي المسجل نفق CONNECT بشكل صحيح مع أهداف HTTPS. الإخفاقات التاريخية ما زالت مهمة، لكن لازم تُقرأ ضمن سياق الإصدار والإعداد. الإعداد المدمج بداية جيدة قليلة التعقيد؛ وعندما تحتاج إلى تحكم لكل طلب، أو دعم SOCKS، أو التدوير، فإن HttpsProxyAgent صريحًا (أو SocksProxyAgent) مع proxy: false يعطيك ملكية أوضح للتوجيه. وإذا كنت تدير التدوير عبر مجموعة بروكسيات في الإنتاج، فإن request وresponse interceptors توفر لك مكان مركزي وقابل للاختبار للقيام بهذا — فقط تأكد أن منطق إعادة المحاولة عندك فيه guard ضد الحلقات، وأنه يعيد فقط الطلبات الآمنة فعلًا لإعادة الإرسال.

احتفظ بجدول التشخيص فوق كمرجع للمرة الجاية اللي يصادفك فيها خطأ غامض في إعداد proxy عند الثانية صباحًا. وإذا لقيت نفسك تقضي وقتًا في إصلاح بنية البروكسي أكثر من الوقت اللي تستخدم فيه البيانات نفسها، يمكن يكون من المفيد تتحقق إذا كانت أداة استخراج API-first تحل المشكلة الحقيقية أسرع بكثير من البنية التحتية.

الأسئلة الشائعة

هل يدعم Axios بروكسيات HTTPS بشكل أصلي؟ نعم في Axios الحالي عند استخدام بروكسي HTTP تقليدي: فالتوثيق الحالي يصف CONNECT tunneling لأهداف HTTPS، ونجح Axios 1.19.0 في هذا المسار في الاختبار المحلي المسجل. أما الإصدارات التاريخية وبعض إعدادات البروكسي المحددة فقد أخرجت أخطاء فعلية، لذلك تحقّق من الإصدار والتكوين الدقيق بدل ما تفترض نجاحًا شاملًا أو فشلًا شاملًا.

كيف أدوّر البروكسيات في Axios؟ استخدم request interceptor لتعيين httpsAgent مختلف من proxy pool قبل إرسال كل طلب، وادمجه مع response interceptor يعيد محاولة الطلبات الفاشلة عبر بروكسي آخر. خلي منطق إعادة المحاولة محدود — مرة واحدة فقط، وللطُرق 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 URL الخاص بك ومرّره كـ httpsAgent في إعدادات Axios — بس تأكد إنك ما تمرر أيضًا HttpsProxyAgent، لأن البروتوكولين يستخدمان أنواع agents مختلفة.

ما الفرق بين خيار proxy وhttpsAgent في Axios؟ خيار proxy هو الإعداد المدمج في Axios لبروكسي واحد ثابت، ويشتغل بشكل جيد في الحالات المباشرة مع الإصدارات الحالية. أما httpsAgent فيقبل agent مخصص من Node.js — مثل HttpsProxyAgent أو SocksProxyAgent — ويعطيك تحكم مباشر لكل طلب في التوجيه والمصادقة والتدوير، وهو شيء ما صُمم الخيار المدمج للتعامل معه.

تعرّف أكثر

• ما هو Web Scraping
• AI Web Scraping
• بدائل Instant Data Scraper
• استخراج بيانات LinkedIn
• استخراج البيانات من الويب بدون برمجة