يعمل cURL على ما يُقدَّر بنحو 20 مليار عملية تثبيت حول العالم — فهو مدمج افتراضيًا في macOS ومعظم توزيعات Linux وWindows 10/11. ومع ذلك، إذا سألت عشرة مطورين عن الطريقة الصحيحة لتمرير طلب cURL عبر بروكسي، فستحصل على عشرة إجابات مختلفة قليلًا، نصفها يتعطل بمجرد دخول المصادقة أو SOCKS في المعادلة.
وهذه هي الفجوة التي أريد سدّها هنا. معظم الشروحات تعرض لك أمرًا واحدًا، تقول لك إنه يعمل، ثم تمضي. لكنها لا تشرح كيف تتأكد من أن البروكسي يقوم فعلًا بشيء ما (والحقيقة: أحيانًا لا يكون كذلك)، وبالتأكيد لا ترشدك إلى رموز الأخطاء التي تظهر فورًا عندما يخرج الإعداد عن المسار المثالي ولو قليلًا. هذا الدليل يغطي الصورة كاملة — بروكسيات HTTP/HTTPS، وSOCKS4/SOCKS5/socks5h، ومتغيرات البيئة (ومطباتها الدقيقة جدًا)، وجدولًا عمليًا لاستكشاف الأخطاء، وماذا تفعل عندما لا يعود cURL والبروكسي كافيين لإنجاز المهمة.
ما هو cURL ولماذا نستخدمه مع بروكسي؟
cURL أداة سطر أوامر لنقل البيانات من وإلى عنوان URL. لا توجد واجهة رسومية، ولا زخارف إضافية — مجرد برنامج يتحدث HTTP وHTTPS وFTP وعددًا من البروتوكولات الأخرى. أبسط استخدام ممكن هو:
curl https://example.com
هذا يجلب الصفحة ويطبع HTML الخام في الطرفية. وهو مفيد بحد ذاته، لكن السبب الحقيقي الذي يجعل المطورين والمستخدمين التقنيين في الأعمال يعتمدون على cURL هو اختبار واجهات API، وجمع البيانات، والتحقق من المحتوى المقيّد جغرافيًا، وتشغيل الطلبات داخل خطوط CI/CD.
يعمل البروكسي كوسيط بين جهازك والخادم المقصود، فيمرر طلبك بالنيابة عنك. الخادم الوجهة يرى عنوان IP الخاص بالبروكسي وليس عنوانك. وهذا مهم لأسباب مشروعة عديدة: مثل اختبار شكل موقعك من بلد آخر، أو تجاوز حدود المعدل أثناء ضمان الجودة، أو توجيه الحركة عبر بوابة الشركة الإلزامية. يدعم cURL النطاق الكامل من بروتوكولات البروكسي — HTTP وHTTPS وSOCKS4 وSOCKS5 — وأكثر الوسائط التي ستراها تتكرر في هذا الدليل هي -x / --proxy (عنوان البروكسي نفسه)، و-v (المخرجات التفصيلية، أفضل صديق لك أثناء التصحيح)، و-k (تجاوز التحقق من SSL، وهو شيء لا ينبغي استخدامه عمليًا خارج بيئات الاختبار).
ملاحظة سريعة قبل أن نواصل: هذا الدليل يتناول آليات الشبكة الخاصة باستخدام بروكسي مع cURL. لكنه ليس تفويضًا لتجاهل شروط استخدام الموقع المستهدف أو سياسات الأمان في مؤسستك. البروكسي يغيّر مسار الشبكة — لكنه لا يغيّر ما هو قانوني أو مسموح.
قبل أن تبدأ
مستوى الصعوبة: مبتدئ إلى متوسط
الوقت المطلوب: نحو 15 دقيقة لفهم الأمثلة الأساسية
ما تحتاجه:
- تثبيت cURL (تحقق باستخدام
curl --version— إذا كنت على macOS أو Linux أو Windows 10/11 فغالبًا هو موجود أصلًا) - بيانات اعتماد البروكسي من مزود الخدمة: المضيف، المنفذ، البروتوكول (HTTP/HTTPS/SOCKS)، واسم المستخدم/كلمة المرور إذا لزم الأمر
- طرفية أو سطر أوامر (Terminal في macOS، أو أي shell في Linux، أو PowerShell / CMD في Windows)
إذا لم يكن cURL مثبتًا لسبب ما، فالأمر بسيط: brew install curl على macOS عبر Homebrew، أو sudo apt install curl على Debian/Ubuntu، أو sudo yum install curl على RHEL/CentOS. وعلى Windows، فهو مرفق مع النظام منذ Windows 10 build 17063.
في هذا الدليل سأستخدم قيمًا بديلة — proxy.example:8080 لعنوان البروكسي وuser:pwd لبيانات الاعتماد. استبدلها ببياناتك الفعلية، ولا تنسخ بيانات دخول حقيقية أبدًا إلى سجل الأوامر أو لقطة شاشة أو رسالة Slack. لقد رأيت كلمات مرور بروكسي مسربة في قنوات Slack أكثر مما أود الاعتراف به.
كيفية استخدام cURL مع بروكسي HTTP أو HTTPS
هذا هو الإعداد الأكثر شيوعًا، وهو ما ستستخدمه في الغالبية العظمى من مهام البروكسي.
استخدام الوسيط -x / --proxy
الصيغة الأساسية تبدو هكذا:
curl -x "http://user:pwd@proxy.example:8080" "https://httpbin.org/ip"
الوسيطان -x و--proxy يفعّلان الشيء نفسه تمامًا — اختر ما يسهل عليك تذكره. وبما أن HTTP هو النمط الافتراضي للبروكسي في cURL، يمكنك نظريًا حذف البادئة http:// وكتابة proxy.example:8080 فقط. لكنني أنصح بكتابتها صراحة، لأنك بعد ستة أشهر ستشكر نفسك على هذا الوضوح.
ضع عنوان URL كاملًا بين علامتي اقتباس مزدوجتين. إذا كانت كلمة المرور تحتوي على @ أو # أو &، فإن السلسلة غير المحاطة باقتباس ستتلفها القشرة البرمجية shell قبل أن يراها cURL أصلًا.
الاتصال عبر بروكسي HTTPS
بعض المزودين يشفّرون الاتصال إلى البروكسي نفسه عبر TLS، وليس فقط الاتصال من البروكسي إلى الوجهة. وهذا يختلف عن زيارة موقع HTTPS — فبروتوكول البروكسي وبروتوكول الوجهة متغيران مستقلان. لتحديد ذلك:
curl -x "https://user:pwd@proxy.example:8080" "https://httpbin.org/ip"
إذا واجهت هنا خطأ في الشهادة، فلا تتسرع في وضع -k والمضي قدمًا. هذا الوسيط يعطل التحقق من شهادة SSL بالكامل، وهو مقبول لاختبار محلي سريع لمدة خمس دقائق، لكنه فكرة سيئة جدًا لأي شيء يلامس الإنتاج أو بيانات المستخدم الحقيقية. إذا كنت تتعامل مع بروكسي مؤسسي يعترض TLS (إعداد MITM شائع في بيئات الشركات)، فالحل الصحيح هو استيراد شهادة CA الخاصة بالبروكسي، لا تعطيل التحقق.
المصادقة باستخدام --proxy-user
يمكنك أيضًا فصل بيانات الاعتماد في وسيط مستقل بدل وضعها داخل عنوان URL:
curl -x "http://proxy.example:8080" --proxy-user "user:pwd" "https://httpbin.org/ip"
انتبه إلى أن -U الكبيرة ليست نفسها مصادقة الموقع الهدف (-u / --user، بحرف صغير) — والخلط بينهما طريقة سهلة لإرسال كلمة مرور البروكسي إلى الوجهة الخطأ. وفي البيئات المؤسسية التي تستخدم NTLM أو Digest بدل Basic، أضف --proxy-ntlm أو --proxy-digest مع --proxy-user.
كيفية استخدام cURL مع بروكسي SOCKS: الفرق بين SOCKS4 وSOCKS5 وsocks5h
بروكسيات SOCKS تعمل على مستوى أدنى من بروكسيات HTTP — فهي لا تهتم بأي بروتوكول تمرّره عبرها، مما يجعلها مفيدة للحركة غير HTTP، ومسارات Tor، وكل ما يرتبط بالخصوصية. معظم الشروحات المنافسة تعطي هذه النقطة أمرًا واحدًا وتمضي. وهذا خطأ، لأن الفروق بين SOCKS4 وSOCKS5 وsocks5h:// مهمة فعلًا.
| الميزة | SOCKS4 | SOCKS5 | socks5h:// |
|---|---|---|---|
| دعم TCP | نعم | نعم | نعم |
| دعم UDP | لا | نعم | نعم |
| المصادقة | لا | نعم | نعم |
| حلّ DNS عن بُعد | لا | لا (DNS محلي) | نعم (البروكسي يحلّه) |
| متوافق مع Tor | لا | محفوف بالمخاطر (تسرب DNS) | نعم |
سطر حلّ DNS هو الذي يوقع الناس في المشكلة فعليًا. مع socks5://، يقوم جهازك بحل اسم المضيف قبل تسليم الاتصال إلى البروكسي — وهذا يعني أن محلل DNS المحلي لديك (وبالتالي مزود الإنترنت) يرى بالضبط النطاق الذي تحاول الوصول إليه، حتى لو كانت حركة HTTP الفعلية تمر عبر البروكسي. أما socks5h:// فيعالج هذا بأن يجعل البروكسي نفسه يقوم بحل اسم المضيف، فلا يتسرب شيء عن الوجهة محليًا. لهذا السبب تصر وثائق Tor على socks5h:// — لأن استخدام socks5:// العادي يبدد جزءًا كبيرًا من إخفاء الهوية الذي يفترض أن يوفّره Tor.
إليك كل صيغة في cURL:
curl --socks4 "proxy.example:1080" "http://example.com"
curl -x "socks5://user:pwd@proxy.example:1080" "http://example.com"
curl -x "socks5h://user:pwd@proxy.example:1080" "http://example.com"
ما لم تكن لديك حاجة محددة لغير ذلك، فاجعل الخيار الافتراضي socks5h://. لا يكلفك شيئًا إضافيًا، ويغلق تسربًا قد لا تلاحظه أبدًا.
ضبط البروكسي عبر متغيرات البيئة (وتجنب الفخاخ)
كتابة -x في كل أمر تصبح مزعجة بسرعة. تتيح لك متغيرات البيئة ضبط البروكسي مرة واحدة في جلسة shell، ثم يرث كل استدعاء لاحق لـ cURL هذا الإعداد تلقائيًا — وتذكر دليل cURL أن المتغيرات المدعومة هي http_proxy وHTTPS_PROXY وALL_PROXY وNO_PROXY.
الأساسيات
export http_proxy="http://user:pwd@proxy.example:8080"
export HTTPS_PROXY="http://user:pwd@proxy.example:8080"
export ALL_PROXY="socks5h://proxy.example:1080"
وهنا نقطة تربك الناس باستمرار: اسم المتغير يشير إلى بروتوكول عنوان URL الهدف، لا بروتوكول البروكسي. لذلك فإن http_proxy يضبط الطلبات المتجهة إلى عناوين http://، وHTTPS_PROXY يضبط الطلبات المتجهة إلى https:// — ويمكنك توجيه الاثنين إلى خادم HTTP proxy نفسه بالضبط، وهذا أمر طبيعي تمامًا.
التجاوز باستخدام NO_PROXY
export NO_PROXY="localhost,127.0.0.1,.internal.example"
القيم مفصولة بفواصل، والنقطة في بداية .internal.example تعمل كبديل عام لكل النطاقات الفرعية. ويطغى NO_PROXY على كل شيء آخر — حتى لو تم تحديد -x صراحة في سطر الأوامر، فإن التطابق داخل NO_PROXY سيتجاوز البروكسي لذلك الطلب.
الأخطاء الشائعة التي توقع الناس فعلًا
- نسيان
export. إذا كتبت فقطhttp_proxy=http://...من دونexport، فإن المتغير يبقى داخل shell الحالية فقط، ولا يراه cURL كعملية فرعية. وهذه، من واقع الخبرة، أكثر سبب شائع لبلاغات الدعم من نوع "البروكسي لا يعمل". - حساسية حالة الأحرف. يفحص cURL تحديدًا المتغير
http_proxyبحروف صغيرة أولًا ويعطيه الأولوية إذا وُجدت النسختان. بعض الأدوات الأخرى تقرأ الصيغة الكبيرة فقط. إذا كنت تحاول فهم لماذا لا يتم التقاط المتغير، فابحث عن نسخة مكررة بحالة أحرف مختلفة. - فخ اختصار PowerShell. في PowerShell 5.1، كتابة
curlلا تستدعي cURL أصلًا — بل تستدعيInvoke-WebRequest، وهي أداة مختلفة تمامًا بوسائط مختلفة. إذا كانت وسيطة-xتعطيك أخطاء غريبة على Windows، فاكتبcurl.exeصراحةً للتأكد من أنك تشغّل cURL فعليًا. - اختلافات بناء الجملة في Windows. يستخدم CMD الأمر
set http_proxy=...; بينما يستخدم PowerShell الصيغة$env:http_proxy = "...". والخلط بينهما بين جلسات الطرفية المختلفة طريقة سهلة لضياع نصف يوم. - بقايا المتغيرات القديمة. الأمران
unset http_proxyوunset https_proxyيزيلان إعداد بروكسي قديمًا كان يوجّه كل الطلبات ويفشلها بصمت.
وللتبديل السريع، فإن بعض الاختصارات في .bashrc توفر وقتًا حقيقيًا:
alias proxyon='export http_proxy="http://proxy.example:8080"; export https_proxy="http://proxy.example:8080"'
alias proxyoff='unset http_proxy; unset https_proxy'
جعل cURL يستخدم بروكسي دائمًا (ملف الإعداد)
إذا كنت خلف بروكسي مؤسسي معظم الوقت، فإن ملف .curlrc (في أنظمة Unix-like داخل مجلد المنزل) أو _curlrc (في Windows داخل مجلد app-data) يضع إعدادًا افتراضيًا ثابتًا من دون لمس متغيرات البيئة على الإطلاق:
proxy="http://proxy.example:8080"
ولأي طلب فردي تريد فيه تجاهله، استخدم --noproxy "*" لتجاوز الإعداد في تلك الاستدعاء فقط. عمومًا تكون الأولوية: وسيط سطر الأوامر > متغير البيئة > ملف الإعداد، لذا فإن -x في سطر الأوامر يفوز دائمًا عند التعارض.
تنبيه مهم: لا تضع كلمة مرور نصية صريحة داخل .curlrc إذا كان الملف مخزنًا في مكان قد يُزامَن أو يُنسخ احتياطيًا أو يُضاف إلى مستودع بالخطأ. في خطوط CI، استخدم مدير الأسرار الخاص بمنصتك، ومرّر بيانات الاعتماد كمتغيرات بيئة مخفية بدلًا من ذلك.
كيف تتحقق من أن البروكسي يعمل فعلًا
هذا هو الجزء الذي تتجاهله تقريبًا كل الشروحات الأخرى، وهو الذي يوفر أكبر قدر من وقت التصحيح. إعداد بروكسي ثم افتراض أنه يمرر الحركة هو سبب ساعات من الاستكشاف لمُجمِّع بيانات لم يكن يستخدم البروكسي أصلًا.
الطريقة 1: قارن عنوان IP الخارجي
شغّل نفس طلب إظهار الـ IP مرتين — مرة مباشرة ومرة عبر البروكسي — ثم قارن بين النتيجتين:
curl https://httpbin.org/ip
curl -x "http://user:pwd@proxy.example:8080" https://httpbin.org/ip
إذا أعاد الأمران عنوان IP نفسه، فالبروكسي لا يفعل شيئًا. راجع صياغة الوسيط، أو متغيرات البيئة، أو ما إذا كان NO_PROXY يطابق الوجهة عن طريق الخطأ.
الطريقة 2: اقرأ المخرجات التفصيلية
أضف -v إلى أي طلب عبر البروكسي، وسيطبع cURL كامل عملية التفاوض:
curl -v -x "http://user:pwd@proxy.example:8080" https://httpbin.org/ip
ابحث عن سطر مثل * Connected to proxy.example (xx.xx.xx.xx) port 8080، يليه > CONNECT httpbin.org:443 HTTP/1.1 ثم < HTTP/1.1 200 Connection established. هذا التسلسل — الاتصال بالبروكسي ثم إنشاء نفق CONNECT إلى الوجهة — هو طريقة HTTP CONNECT وهي بالضبط ما ينبغي أن يحدث عند توجيه وجهة HTTPS عبر بروكسي HTTP. إذا لم يظهر سطر CONNECT مطلقًا، فهذا يعني أن وسيط البروكسي لم يُطبَّق. تنبيه أثناء استخدامك لهذا الأسلوب: استخدم -v فقط أثناء التصحيح النشط، واحذف أو أخفِ المخرجات قبل مشاركتها في أي مكان — فقد يطبع الوضع التفصيلي بيانات اعتماد البروكسي نصًا صريحًا.
الطريقة 3: مقارنة جانبية بين المخرجات
لأغراض اختبار المواقع جغرافيًا تحديدًا، احفظ المخرجات في ملفين ثم قارن بينهما:
curl https://httpbin.org/ip > direct.json
curl -x "http://user:pwd@proxy.example:8080" https://httpbin.org/ip > proxied.json
diff direct.json proxied.json
إذا اختلفت استجابات الصفحة (أو الترويسات، في حالة المحتوى المقيد جغرافيًا)، فهذه إشارة مرئية واضحة إلى أن البروكسي غيّر مسار الشبكة فعلًا — وهي طريقة سريعة قليلة الجهد لحسم أي شك قبل الغوص أعمق.
استكشاف أخطاء بروكسي cURL الشائعة وإصلاحها
معظم الأدلة تمر على هذا القسم مرورًا سريعًا وتذكر -k مرة واحدة. لكن هذا الموضوع يستحق جدولًا مرجعيًا حقيقيًا.
| الخطأ | السبب المحتمل | الحل |
|---|---|---|
curl: (7) Failed to connect | مضيف/منفذ البروكسي خاطئ، أو أن البروكسي متوقف | تحقّق من العنوان؛ واختبر الاتصال الخام باستخدام telnet host port أو nc -zv host port |
407 Proxy Authentication Required | بيانات اعتماد البروكسي مفقودة أو غير صحيحة | أضف --proxy-user user:pass; وتحقق مما إذا كان المزود يتطلب NTLM/Digest/Negotiate بدل Basic |
curl: (56) Recv failure: Connection reset by peer | البروكسي أسقط الاتصال أثناء النقل | تحقّق من استقرار البروكسي مع المزود؛ وإذا كان بروكسيًا ينهي TLS، فراجع التعامل مع الشهادات بدل تعطيل التحقق بالقوة |
curl: (28) Connection timed out | جدار ناري يحجب الاتصال، أو بروكسي قديم، أو منفذ خاطئ | شغّل `env |
| فشل التحقق من الشهادة | شهادة بروكسي غير موثوقة أو تعترض الاتصال | احصل على سلسلة CA الصحيحة واستخدم --proxy-cacert; وتجنب تعطيل التحقق خارج حالة تشخيص عابرة |
أفضل خطوة أولى مشتركة لكل هذه الحالات هي إضافة -v. فهذا يخبرك بالضبط أين ينقطع الاتصال — عند حل DNS، أو اتصال TCP، أو تفاوض TLS، أو تبادل مصادقة البروكسي — بدلًا من أن تظل تخمّن استنادًا إلى رمز خطأ من ثلاثة أرقام.
وفي البيئات المؤسسية تحديدًا، يتولى --proxy-ntlm و--proxy-negotiate أنماط مصادقة نطاقات Windows. وهناك شيء واحد لا يعالجه cURL محليًا فعلًا: ملفات PAC (Proxy Auto-Config) وهي سكربتات تستخدمها بعض الشركات لتعيين البروكسيات بشكل ديناميكي. إذا كانت شركتك تستخدمها، فستحتاج إلى استخراج مضيف البروكسي والمنفذ الفعليين يدويًا — عادةً من إعدادات الشبكة في المتصفح — لأن cURL لا يملك محلل PAC مدمجًا.
متى لا يكون cURL + بروكسي كافيين
يتعامل cURL مع البروكسي مع HTML الثابت، واستدعاءات REST API، وجلب البيانات البسيطة بكفاءة ممتازة. لكن ما يعرقله هو حواجز الويب الحديث المفضلة: التطبيقات أحادية الصفحة المعروضة بجافاسكربت، وأنظمة مكافحة البوت مثل Cloudflare أو Akamai، وجدران CAPTCHA. إذا وجّهت cURL إلى تطبيق React أو Vue محمي بأحد هذه الأنظمة، فغالبًا ستحصل على <div id="root"></div> فارغ — طلب ناجح تقنيًا، لكنه عديم الفائدة عمليًا. هذه ليست مشكلة في cURL. إنه ببساطة ليس متصفحًا، ولم يدّعِ يومًا أنه كذلك.
إذا كنت مرتاحًا أصلًا لتشغيل cURL من الطرفية وواجهت هذا الحاجز، فخطوتك التالية الطبيعية ليست الانتقال إلى سلسلة أدوات مختلفة تمامًا — بل إضافة طبقة تتولى العرض البنيوي والتنظيم نيابة عنك. هذه هي الفجوة التي صُممت أدوات المطورين في Thunderbit لسدّها.
| السيناريو | cURL + بروكسي | Thunderbit API (POST /extract) |
|---|---|---|
| صفحة HTML ثابتة | يعمل بشكل ممتاز | يعمل ويعيد بيانات منظّمة أيضًا |
| تطبيق SPA معروض بجافاسكربت | يعيد HTML فارغًا/ناقصًا | renderMode: "full" يعالج JavaScript |
| مكافحة البوت / CAPTCHA | محجوب | معالجة مدمجة |
| إخراج بيانات منظّمة | HTML خام — عليك تحليله يدويًا | JSON عبر مخططك الخاص |
| دفعات كبيرة (100+ URL) | حلقة يدوية + إدارة معدل الطلبات بنفسك | POST /batch/extract |
توفّر واجهة Thunderbit المفتوحة نقطة نهاية /extract تُرجع JSON مطابقًا للمخطط مباشرة من الصفحات الثقيلة بجافاسكربت، ونقطة /distill لتحويل المحتوى إلى Markdown نظيف — وكلتاهما قابلتان للاستدعاء من الجلسة الطرفية نفسها التي كنت تستخدم فيها أوامر cURL طوال الوقت. كما يوجد خادم MCP لمساعدات البرمجة بالذكاء الاصطناعي مثل Claude أو Cursor، وأداة CLI (npx @thunderbit/thunderbit-cli extract <url> --schema fields.json) إذا كنت تفضّل البقاء داخل السكربتات بالكامل. لا شيء من هذا يستبدل cURL في المهام التي يتقنها cURL — لكنه يكمّل ما لا يستطيع cURL تجاوزه بنيويًا. وإذا أردت الصورة الأشمل حول مكان الاستخراج بمساعدة الذكاء الاصطناعي مقارنةً بكتابة منطقك الخاص لجمع البيانات، فاطّلع على شرحنا حول استخراج البيانات من الويب بالذكاء الاصطناعي ومقارنتنا لأفضل أفضل أدوات استخراج بيانات الويب بالذكاء الاصطناعي، كما أن مقال استخراج البيانات من الويب بدون برمجة سيكون مدخلًا جيدًا إذا كنت تنظر إلى الموضوع من زاوية أعمال لا من زاوية هندسية.
الخلاصة
إن جعل cURL والبروكسي يتواصلان بشكل صحيح ليس أمرًا صعبًا متى عرفت أين تقع نقاط الفشل الحقيقية — والمفاجأة أن معظمها ليس البروكسي نفسه. نسيان export. الخلط بين -u و-U. استخدام socks5:// بينما كنت تقصد socks5h://. تشغيل اختصار curl الخاص بـ PowerShell بدل curl.exe. كل واحدة من هذه الحالات تنتج خطأً مربكًا وعامًا لا علاقة له بمزوّد البروكسي.
العادة التي توفر أكثر وقت: تحقّق قبل أن تستكشف الخطأ. شغّل فحص الـ IP، وألقِ نظرة سريعة على مخرجات -v، وتأكد من أن البروكسي موجود أصلًا في مسار الطلب قبل أن تفترض أن المشكلة في مكان آخر. وعندما يبدأ الهدف بإرسال JavaScript بدل HTML نظيف، فهذه ليست مشكلة cURL تُحلّ بمزيد من الوسائط — بل إشارة إلى أنك تحتاج أداة مبنية للعرض، مثل واجهة Thunderbit API، التي توفر خطة مجانية إذا أردت أن ترى بنفسك الفرق بين إخراج JSON وبين HTML الخام.
الأسئلة الشائعة
هل يستخدم cURL بروكسيًا افتراضيًا؟
لا. ما لم تكن قد ضبطت متغيرات البيئة http_proxy / HTTPS_PROXY أو أعددت ملف .curlrc، فسيتصل cURL مباشرة بالوجهة من دون أي بروكسي.
كيف أوقف cURL عن استخدام البروكسي في طلب واحد فقط؟
أضف --noproxy "*" إلى ذلك الأمر تحديدًا. ولإزالته طوال جلسة shell، نفّذ unset http_proxy && unset https_proxy.
هل يمكنني استخدام cURL مع بروكسيات متناوبة؟
نعم — إذا كان مزودك يوفّر بوابة تدوير (نقطة نهاية واحدة تمنح عنوان IP جديدًا مع كل طلب)، فما عليك إلا توجيه -x إلى عنوان تلك البوابة مثل أي بروكسي آخر. أما بالنسبة لمنطق التدوير الأكثر تعقيدًا مع الأهداف المعروضة بجافاسكربت، فإن طبقة API مثل Thunderbit تتعامل مع التدوير ومكافحة البوت داخليًا، فلا تحتاج إلى إدارة منطق إعادة المحاولة يدويًا.
لماذا يتسبب socks5:// في تسرب طلبات DNS بينما لا يفعل socks5h:// ذلك؟
مع socks5://، يحل جهازك المحلي اسم المضيف المستهدف قبل إرسال طلب الاتصال إلى البروكسي — ما يعني أن محلل DNS لدى مزود الإنترنت يرى النطاق الذي تزوره. أما socks5h:// فينقل حل اسم المضيف إلى البروكسي نفسه، فلا يظهر أي شيء عن الوجهة محليًا.
هل استخدام cURL مع بروكسي قانوني؟
استخدام البروكسي قانوني في معظم الولايات القضائية بحد ذاته. المهم هو ما تفعله به — احترم دائمًا شروط استخدام الموقع المستهدف وrobots.txt حيث ينطبق، وأي قوانين ذات صلة بحماية البيانات والخصوصية. هذا الدليل يشرح الآليات التقنية فقط، وليس منحًا قانونيًا بالإذن لأي حالة استخدام بعينها.
معرفة المزيد
