يبدو إعداد Wget مع البروكسي وكأنه شغل خمس ثوانٍ بس — إلى أن تمر ساعة كاملة وأنت تحاول تفهم ليه الطلبات تتجاوز البروكسي تمامًا من غير أي رسالة خطأ. شفت هذا يحصل مع مسؤولي أنظمة مخضرمين ومع مطورين مبتدئين بنفس الشكل.
وغالبًا المشكلة أصلًا ما تكون في البروكسي نفسه، بل في الأماكن الأربعة المختلفة اللي يقدر Wget يقرأ منها إعدادات البروكسي، وفي فشل الإعدادات بصمت لما يكون اسم المتغير بحالة أحرف غلط، وفي تفاصيل شبكات الشركات اللي ما يشرحها أي دليل رسمي بشكل كافٍ. هذا الدليل يغطي كل طريقة لإعداد Wget مع بروكسي، وقواعد الأولوية الدقيقة لما تتعارض الطرق المختلفة، ومخرجات الطرفية الفعلية لكل خطأ شائع، بالإضافة إلى قسم مخصص لمستخدمي Windows والشبكات المؤسسية — وهي الفئة اللي تقريبًا كل الشروحات الثانية تتجاهلها.
- مستوى الصعوبة: من مبتدئ إلى متوسط
- الوقت المطلوب: حوالي 15 دقيقة للقراءة والإعداد؛ وحوالي دقيقتين فقط بعد ما تتقن الموضوع
- ما ستحتاجه: تثبيت شغال لـ Wget (التعليمات تحت)، وعنوان بروكسي (المضيف + المنفذ)، وربما بيانات اعتماد للبروكسي
جرّب Thunderbit لاستخراج البيانات المهيكلة
ما هو Wget ولماذا قد تستخدمه مع بروكسي؟
Wget هو أداة سطر أوامر لتنزيل الملفات وصفحات الويب من الإنترنت من غير ما تحتاج متصفح. وتوثيق GNU الرسمي يصفه بأنه "أداة تنزيل شبكي غير تفاعلية" — يعني يشتغل في الخلفية، ويكمل التنزيلات المتقطعة، ويتعامل مع التنزيلات التكرارية من غير ما أحد يضغط أي شيء.
أما البروكسي فهو خادم وسيط. بدل ما جهازك يتصل بالموقع المستهدف مباشرة، يرسل Wget الطلب إلى البروكسي، والبروكسي هو اللي يمرره. ومن أهم الأسباب اللي تخليك تستخدمه:
- الالتزام بجدار الحماية داخل الشركات — لأن الشركة تشترط أن كل الاتصالات الخارجية تمر عبر بروكسي معتمد
- الخصوصية وإدارة عنوان IP — بحيث تظهر الطلبات وكأنها صادرة من IP البروكسي بدل جهازك
- اختبار المناطق الجغرافية — لجلب موارد مقيدة جغرافيًا أو اختبار سلوك شبكة CDN من منطقة معينة
- خطوط جمع البيانات — لتنزيل HTML عبر بروكسيات متناوبة لأغراض البحث أو المراقبة
- بيئات CI/CD — لما تكون المهام شغالة داخل شبكات مقيدة ما تسمح بالوصول للإنترنت إلا عبر بروكسي
يدعم Wget بشكل أصلي بروكسيات HTTP وHTTPS وFTP. لكنه لا يدعم SOCKS5. وإذا كنت تحتاج SOCKS5، فـ curl يدعمه بشكل أصلي عبر socks4:// وsocks5:// وsocks5h:// — أو تقدر تشغل Wget عبر أداة مثل proxychains4.
كيفية تثبيت Wget على Linux وmacOS وWindows
قبل إعداد البروكسي، لازم يكون Wget مثبت على جهازك. هذا الجزء سريع لأنه مجرد متطلب مسبق، وليس لب الموضوع.
Linux (Debian/Ubuntu وRHEL/CentOS)
# Debian/Ubuntu
sudo apt update
sudo apt install wget
# RHEL/CentOS/Fedora
sudo dnf install wget
# التحقق
wget --version
تأتي Ubuntu 24.04 LTS مع Wget 1.21.4، بينما Debian Trixie لديها الإصدار 1.25.0. وتعرض حزم CentOS Stream 10 الإصدار 1.24.5.
macOS (Homebrew)
brew install wget
wget --version
صيغة Homebrew الرسمية توفر حاليًا Wget 1.25.0 المستقر، مع 396,818 عملية تثبيت خلال العام الماضي.
Windows (Chocolatey والتثبيت اليدوي)
choco install wget
wget --version
تشير حزمة GNU Wget على Chocolatey إلى أكثر من 10 ملايين تنزيل إجمالي، رغم أنها حاليًا عند الإصدار 1.21.4. وغالبًا يكون الملف التنفيذي موجودًا في C:\ProgramData\chocolatey\bin\wget.exe.
ملاحظة مهمة لمستخدمي Windows: المكان اللي يبحث فيه Wget عن ملف .wgetrc يختلف حسب طريقة البناء. التفاصيل في قسم Windows تحت.
4 طرق لاستخدام Wget مع بروكسي (وأيها تختار)
هناك أربع طرق، ولكل طريقة نطاق وتأثير وأولوية مختلفة:
- وسيطات سطر الأوامر
-e— للاستخدام مرة واحدة مع أمر واحد - ملف إعدادات المستخدم (
~/.wgetrc) — يطبق على كل أوامر Wget اللي تشغلها - ملف إعدادات النظام (
/etc/wgetrc) — يطبق على كل المستخدمين على الجهاز - متغيرات البيئة (
http_proxy،https_proxy) — تطبق على جلسة الطرفية بالكامل
الطريقة 1: وسائط سطر الأوامر (بروكسي لمرة واحدة)
مناسبة للاختبارات السريعة. الإعدادات تختفي بمجرد انتهاء الأمر.
wget -e use_proxy=on -e http_proxy=http://HOST:PORT/ http://example.com/file.zip
للوجهات عبر HTTPS:
wget -e use_proxy=on -e https_proxy=http://HOST:PORT/ https://example.com/
اختبار سريع — جلب عنوان IP الظاهر لديك عبر البروكسي:
wget -qO- -e use_proxy=on -e http_proxy=http://HOST:PORT/ http://ifconfig.me
إذا طلع لك عنوان IP الخاص بالبروكسي بدل عنوانك، فأنت ماشي صح.
الطريقة 2: ملف إعدادات المستخدم (~/.wgetrc)
أضف هذه الأسطر إلى ~/.wgetrc (أنشئ الملف إذا ما كان موجودًا):
use_proxy = on
http_proxy = http://proxy.company.com:8080/
https_proxy = http://proxy.company.com:8080/
no_proxy = localhost,127.0.0.1,.internal.company.com
لاحظ وجود مسافة قبل وبعد = — هذا هو التنسيق الموثق لملف .wgetrc. من الآن فصاعدًا، كل أمر Wget تشغله بهذا المستخدم سيمر عبر البروكسي.
الطريقة 3: إعدادات على مستوى النظام (/etc/wgetrc)
نفس التعليمات الموجودة في ~/.wgetrc، لكن توضع في ملف إعدادات النظام. GNU تصف هذا الملف بأنه ملف بدء عام — والمسار الدقيق يعتمد على مكان التثبيت عندك. من المواقع الشائعة:
/etc/wgetrc(معظم مديري حزم Linux)/usr/local/etc/wgetrc(بعض نسخ Homebrew)- المسار الظاهر في ناتج
wget --versionتحت "Wgetrc:"
هذا مفيد للخوادم المشتركة أو حاويات Docker أو أي بيئة لازم كل الحسابات فيها تمر عبر نفس البروكسي.
الطريقة 4: متغيرات البيئة (http_proxy / https_proxy)
export http_proxy=http://HOST:PORT/
export https_proxy=http://HOST:PORT/
export no_proxy=localhost,127.0.0.1,.internal.company.com
هذه المتغيرات تؤثر في جلسة الطرفية كلها — وليس Wget فقط. كما ستتعرف عليها أدوات مثل curl أيضًا.
تحذير مهم: Wget يقرأ أسماء متغيرات البيئة المكتوبة بحروف صغيرة فقط. أما HTTP_PROXY بالأحرف الكبيرة فيتجاهله بصمت. لا رسالة خطأ، لا تحذير، ولا شيء. سأوضح النتيجة الدقيقة في قسم الأخطاء الشائعة، لكن الأفضل تحفظ هذه القاعدة الآن.
أولوية طرق البروكسي: ماذا يتغلب على ماذا عند تعارض الإعدادات؟
إذا كان عندك بروكسي مضبوط في متغيرات البيئة وأيضًا في .wgetrc وأيضًا في سطر الأوامر، فأي واحد يشتغل؟ هذه نقطة كثير ناس ما يشرحونها بوضوح، لذلك اختبرتها بنفسي.
هذه هي الأولوية المختبرة والموثقة:
| الأولوية | الطريقة | النطاق | ما الذي تتجاوزه |
|---|---|---|---|
| 1 (الأعلى) | وسائط CLI من نوع -e | أمر واحد | كل شيء |
| 2 | ~/.wgetrc | المستخدم الحالي | إعدادات النظام + متغيرات البيئة |
| 3 | /etc/wgetrc | على مستوى النظام | متغيرات البيئة فقط |
| 4 (الأدنى) | متغيرات البيئة http_proxy / https_proxy | جلسة الطرفية | لا شيء |
تحققت من هذا على Wget 1.25.0 عبر ضبط بروكسيات متعارضة في كل مستوى. لما كانت البيئة على المنفذ 3128، وملف الإعدادات على 3129، وCLI على 3130:
- الإعدادات تتغلب على البيئة: اتصل Wget بالمنفذ 3129 وتجاهل 3128.
- CLI يتغلب على الإعدادات: اتصل Wget بالمنفذ 3130 وتجاهل 3129 و3128 معًا.
خيار الخروج من كل هذا هو --no-proxy. فهو يتجاوز كل إعدادات البروكسي بغض النظر عن مكان تعريفها:
wget --no-proxy https://internal-server.company.com/report.pdf
سيناريو عملي: مسؤول النظام ضبط بروكسي في /etc/wgetrc، لكنك تحتاج الوصول إلى خادم داخلي مباشرة. استخدم --no-proxy لهذا الأمر فقط بدل تعديل ملف إعدادات النظام.
كيفية استخدام Wget مع بروكسي يتطلب تسجيل دخول
كثير من بروكسيات الأعمال أو المنازل تحتاج اسم مستخدم وكلمة مرور. ويدعم Wget ذلك بطريقتين، وكلتا الطريقتين تستخدم مصادقة HTTP Basic لبيانات اعتماد البروكسي.
تضمين بيانات الاعتماد داخل عنوان البروكسي
wget -e use_proxy=on \
-e http_proxy=http://USERNAME:PASSWORD@proxy.company.com:8080/ \
http://example.com/file.zip
ويعمل هذا أيضًا داخل .wgetrc:
http_proxy = http://USERNAME:PASSWORD@proxy.company.com:8080/
https_proxy = http://USERNAME:PASSWORD@proxy.company.com:8080/
استخدام الوسيطتين --proxy-user و --proxy-password
wget --proxy-user=USERNAME --proxy-password=PASSWORD \
-e use_proxy=on \
-e http_proxy=http://proxy.company.com:8080/ \
http://example.com/file.zip
هذه الوسائط تتجاوز أي بيانات اعتماد مضمّنة بصيغة user:pass@ داخل عنوان البروكسي.
كيف تحافظ على بيانات الاعتماد بأمان
كلتا الطريقتين قد تكشفان بيانات الاعتماد. GNU تحذر من أن كلمات المرور على سطر الأوامر قد تظهر عبر ps أو أدوات عرض العمليات. وطرق التخفيف:
- الأجهزة ذات المستخدم الواحد: خزّن بيانات الاعتماد في
~/.wgetrcثم احمِ الملف:chmod 600 ~/.wgetrc - خطوط CI/CD: استخدم الأسرار المشفرة في GitHub Actions أو ما يعادلها في منصتك. مررها كمتغيرات بيئة بحروف صغيرة داخل تعريف الخطوة — ولا تضعها داخل YAML بشكل ثابت أبدًا.
- بناءات Docker: لا تستخدم
ARGأوENVللأسرار. وثائق Docker توضح صراحة أن وسائط البناء قد تبقى داخل الصورة النهائية. استخدم بدل ذلك أسرار BuildKit. - التحكم بالإصدارات: لا ترفع ملف
.wgetrcالذي يحتوي على بيانات اعتماد إلى المستودع. أضفه إلى.gitignore.
تفصيل مهم خاص بـ Wget في GitHub Actions: أسماء الأسرار عادة تُخزن بحروف كبيرة حسب العرف، لكن متغيرات البيئة اللي تعرضها لـ Wget لازم تكون بحروف صغيرة (http_proxy وليس HTTP_PROXY).
كيفية استخدام Wget مع بروكسي على Windows وداخل الشبكات المؤسسية
معظم المقالات في هذا الموضوع تتوقف عند عبارة "ثبته عبر Chocolatey". لكن إذا كنت على Windows أو خلف بروكسي مؤسسي، هنا تبدأ المتاعب فعلًا.
أين يبحث Windows عن .wgetrc
توثيق GNU يقول إن Wget يقرأ $HOME/.wgetrc ما لم يشِر متغير البيئة WGETRC إلى مكان آخر. وعلى Windows، قد يكون $HOME هو %USERPROFILE% مثل C:\Users\alice، أو قد لا يكون — حسب ما إذا كنت تستخدم نسخة Chocolatey أو MSYS2 أو Git Bash أو ملفًا تنفيذيًا مستقلًا.
توصيتي: لا تخمن، واستخدم الوسيط --config لسلوك حتمي:
wget --config=C:\Users\alice\wgetrc https://example.com/file.zip
لاختبار ما إذا كانت نسختك تقرأ ملف إعدادات من موقع معين، أنشئ ملف اختبار يشير إلى بروكسي معروف أنه خاطئ:
; C:\Users\alice\wget-test.rc
use_proxy = on
http_proxy = http://127.0.0.1:3128/
ثم شغّل:
wget --config=C:\Users\alice\wget-test.rc --spider http://example.com/
إذا حاول Wget الاتصال بـ 127.0.0.1:3128 فهذا يعني أنه قرأ الملف.
ضبط متغيرات البروكسي على Windows
CMD (لجلسة واحدة فقط):
set http_proxy=http://HOST:PORT/
set https_proxy=http://HOST:PORT/
wget http://example.com/
PowerShell (لجلسة واحدة فقط):
$env:http_proxy = "http://HOST:PORT/"
$env:https_proxy = "http://HOST:PORT/"
wget http://example.com/
دائمًا (يبقى بعد إعادة التشغيل):
setx http_proxy http://HOST:PORT/
setx https_proxy http://HOST:PORT/
بعد setx لازم تفتح نافذة طرفية جديدة. الجلسة الحالية لن ترى التغيير.
أخطاء البروكسي المؤسسي: ملفات PAC، مصادقة NTLM، وكيف تجد عنوان بروكسيك
هناك ثلاثة أشياء تربك مستخدمي الشركات باستمرار:
ملفات PAC: كثير من المؤسسات تستخدم ملفات Proxy Auto-Configuration (PAC) — وهي سكربتات مبنية على JavaScript تقول للمتصفح أي بروكسي يستخدم لكل عنوان URL. Wget ما عنده محرك JavaScript، لذلك لا يستطيع قراءة ملفات PAC. وتذكر وثائق curl نفس النقطة. الحل: افتح ملف PAC (أو اسأل قسم تقنية المعلومات)، وابحث عن نتيجة PROXY host:port للنطاق المستهدف، ثم ضع هذا العنوان الثابت في Wget.
مصادقة NTLM: Wget يدعم فقط المصادقة الأساسية Basic لمصادقة البروكسي. إذا كان بروكسي الشركة يحتاج NTLM وكنت ترى الخطأ 407 Proxy Authentication Required، فلا تضيع وقتك في تجربة صيغ مختلفة لـ --proxy-user. ثبّت Cntlm — وهو وسيط محلي يتعامل مع مصادقة NTLM/NTLMv2 ويقدم واجهة Basic auth إلى Wget. وما زال Cntlm محدثًا حتى الآن (آخر تحديث في أكتوبر 2025، وحوالي 395 تنزيلًا أسبوعيًا).
شجرة قرار لمستخدمي البروكسي المؤسسي:
- جرّب
set http_proxy=http://YOUR_PROXY:PORT/ثم شغّل Wget. - إذا ظهر خطأ
407وكانت شركتك تستخدم NTLM → ثبّت Cntlm، واضبطه ببيانات اعتماد النطاق، ثم وجّه Wget إلى المنفذ المحلي لـ Cntlm (عادةًhttp://127.0.0.1:3128/). - إذا كانت الشركة تستخدم ملف PAC → استخرج
PROXY host:portالفعلي من الملف أو اطلب من قسم تقنية المعلومات عنوان البروكسي الثابت.
أكثر المنافذ الشائعة في بروكسيات الشركات: 3128 (نمط Squid)، و8080 (بروكسي HTTP عام)، و8888 (بروكسيات تشخيص مثل Fiddler/Charles). هذه مجرد أعراف وليست ضمانات.
الأخطاء الشائعة عند استخدام Wget مع بروكسي (مع مخرجات الخطأ الحقيقية)
والآن إلى الجزء اللي وعدنا به في العنوان. كل المخرجات التالية أُعيد إنتاجها على Wget 1.25.0 (macOS، عبر Homebrew) في 2026-06-01.
الخطأ 1: نسيان البادئة http://
بعض الأدلة القديمة تقول إن هذا يكسر الإعداد دائمًا. لكن في Wget 1.25.0، ضبط http_proxy=127.0.0.1:3128 يشتغل فعلًا — لأن Wget يضيف http:// تلقائيًا بصمت:
Prepended http:// to '127.0.0.1:3128'
Spider mode enabled. Check if remote file exists.
--2026-06-01 10:38:15-- http://example.com/
Connecting to 127.0.0.1:3128... failed: Operation not permitted.
ومع ذلك، فقد اتصل بالبروكسي الصحيح. لكني أنصح دائمًا بإضافة البادئة http:// مع شرطة مائلة نهائية /. هذا يزيل أي التباس بين الإصدارات، ويخلي صيغة بيانات الاعتماد (http://user:pass@host:port/) واضحة تمامًا.
الخطأ 2: use_proxy=yes مقابل use_proxy=on
القيمتان yes وon عملتا في اختباراتي على Wget 1.25.0. لكن القيم غير الصالحة تفشل برسالة واضحة:
wget: use_proxy: Invalid boolean 'true'; use `on' or `off'.
استخدم on للحصول على أوسع قدر من التوافق — فهو متماشي مع الصيغة الموثقة للقيم المنطقية في الدليل ومع التلميح الموجود في رسالة الخطأ نفسها.
الخطأ 3: تجاهل HTTP_PROXY بالأحرف الكبيرة بصمت
هذا أكثر خطأ مزعج، لأن ما فيه أي رسالة خطأ إطلاقًا. فقط Wget يتصل مباشرة وكأنك ما ضبطت بروكسي أصلًا.
الأحرف الكبيرة (غير صحيح — لم يُستخدم أي بروكسي):
HTTP_PROXY=http://127.0.0.1:3128/ wget --no-config --spider http://example.com/
Spider mode enabled. Check if remote file exists.
--2026-06-01 10:40:06-- http://example.com/
Resolving example.com (example.com)... 198.18.58.61
Connecting to example.com (example.com)|198.18.58.61|:80... connected.
HTTP request sent, awaiting response... 200 OK
الأحرف الصغيرة (صحيح — تمت محاولة استخدام البروكسي):
http_proxy=http://127.0.0.1:3128/ wget --no-config --spider http://example.com/
Spider mode enabled. Check if remote file exists.
--2026-06-01 10:40:16-- http://example.com/
Connecting to 127.0.0.1:3128... failed: Connection refused.
شايف الفرق؟ النسخة ذات الأحرف الكبيرة حلت example.com مباشرة. أما النسخة ذات الأحرف الصغيرة فحاولت تستخدم البروكسي. ولا تحذير في أي من الحالتين. وcurl عنده سلوك مشابه — فهو يقبل الأحرف الكبيرة في معظم متغيرات البروكسي، لكنه يرفض HTTP_PROXY تحديدًا لأسباب أمنية.
الإصلاح: استخدم دائمًا http_proxy وhttps_proxy بحروف صغيرة.
الخطأ 4: بروكسي قديم في .wgetrc يسبب "Connection Refused"
إذا تركت أنت — أو مسؤول النظام — أو صورة Docker — عنوان بروكسي قديمًا في ملف الإعدادات، فستشوف شيئًا مثل هذا:
Spider mode enabled. Check if remote file exists.
--2026-06-01 10:39:10-- http://example.com/
Connecting to 127.0.0.1:3128... failed: Connection refused.
الخطأ يشير إلى IP البروكسي القديم، لا إلى الموقع المستهدف. وترتيب الفحص يكون كالتالي (حسب هرمية الأولوية):
- افحص الأمر بحثًا عن وسائط
-eأو أي aliases في shell - افحص
~/.wgetrc(أو الملف الذي يحددهWGETRC) - افحص إعدادات النظام (المسار يظهر في
wget --version) - افحص البيئة:
env | grep -i proxy
ولأغراض التشخيص، --no-config هو صديقك — لأنه يطلب من Wget تجاهل كل ملفات الإعداد:
wget --no-config --spider http://example.com/
إذا نجح هذا، فالمشكلة في أحد ملفات الإعدادات.
الخطأ 5: ارتباك صيغة بروكسي HTTPS
هذا يوقع ناس كثيرين. عند ضبط https_proxy، يكون عنوان البروكسي نفسه غالبًا http:// وليس https://. السبب أن Wget يرسل طلب HTTP CONNECT عبر البروكسي لإنشاء نفق لجلسة HTTPS المشفرة.
الصحيح:
https_proxy=http://proxy.company.com:8080/
wget https://example.com/
يرسل Wget CONNECT example.com:443 HTTP/1.1 إلى البروكسي، ثم يمرر HTTPS عبر النفق.
الخاطئ (لعناوين URL عبر HTTP مع نقطة بروكسي HTTPS):
http_proxy=https://127.0.0.1:18082/
wget http://example.com/
Error in proxy URL https://127.0.0.1:18082/: Must be HTTP.
Wget 1.25.0 يرفض عنوان البروكسي https:// لوجهات HTTP مباشرة. استخدم https_proxy=http://HOST:PORT/ إلا إذا كانت مؤسستك وثقت صراحة نقطة بروكسي HTTPS واختبرتها على نسختك من Wget.
ورقة غش أوامر Wget مع البروكسي (مرجع سريع قابل للحفظ)
احفظ هذا الجدول عندك. فهو يجمع كل وسائط Wget وتعليمات الإعداد المتعلقة بالبروكسي في مكان واحد.
| الوسيط / التعليمات | السياق | مثال | ملاحظات |
|---|---|---|---|
-e use_proxy=on | CLI | -e use_proxy=on | on هو الخيار الأكثر أمانًا؛ وبعض الإصدارات تقبل أيضًا yes |
-e http_proxy= | CLI | -e http_proxy=http://proxy:8080/ | أضف بادئة http:// مع شرطة مائلة نهائية / |
-e https_proxy= | CLI | -e https_proxy=http://proxy:8080/ | عنوان البروكسي يكون غالبًا http:// حتى لوجهات HTTPS |
--proxy-user | CLI | --proxy-user=admin | يتجاوز user:pass@ المضمن |
--proxy-password | CLI | --proxy-password=secret | يظهر في ps — تجنبه على الأنظمة المشتركة |
--no-proxy | CLI | --no-proxy | يتجاوز كل إعدادات البروكسي من جميع المصادر |
--no-config | CLI | --no-config | يتجاوز كل ملفات الإعداد — مفيد للتشخيص |
--config=FILE | CLI | --config=/tmp/wgetrc | مسار إعدادات حتمي — ممتاز لـ Windows وCI |
http_proxy | .wgetrc / env | http_proxy = http://proxy:8080/ | ملف الإعدادات يستخدم مسافات حول =؛ ومتغير البيئة يجب أن يكون بحروف صغيرة |
https_proxy | .wgetrc / env | https_proxy = http://proxy:8080/ | نفس صيغة http_proxy |
ftp_proxy | .wgetrc / env | ftp_proxy = http://proxy:8080/ | لجلب ملفات FTP |
no_proxy | .wgetrc / env | no_proxy = localhost,127.0.0.1,.corp | قائمة نطاقات مفصولة بفواصل |
proxy_user | .wgetrc | proxy_user = admin | مكافئ لـ --proxy-user |
proxy_password | .wgetrc | proxy_password = secret | احمِ الملف عبر chmod 600 |
متى لا يكون Wget مع بروكسي هو الخيار الصحيح؟ وماذا تستخدم بدلًا منه؟
بعد كل هذا الإعداد للبروكسي، عندي رأي مخالف قليلًا: أحيانًا ما تحتاج كل هذا أصلًا.
كثير من الناس اللي يبحثون عن "wget proxy" ما يحاولون فعليًا تنزيل ملف واحد فقط. هم يريدون جمع بيانات منظمة من مواقع ويب — مثل أسعار المنتجات، وقوائم جهات الاتصال، وإعلانات العقارات — ولجؤوا إلى Wget لأنه الأداة الطرفية اللي يعرفونها. المشكلة أن Wget يعطيك HTML خام، وبعدها عليك تحلله وتنظفه وتعيد هيكلته. وإذا كنت تستخدم بروكسيات متناوبة لتفادي الحظر، فستجد نفسك تدير قائمة بروكسيات، وسكربت تنزيل، ومحلل، وخط تصدير كامل.
| هدفك | الأداة الأنسب | السبب |
|---|---|---|
| تنزيل ملف واحد عبر بروكسي | wget مع وسائط البروكسي | بسيط، بأمر واحد |
| نسخ موقع أو مجلد عبر بروكسي | wget --recursive + إعداد البروكسي | التنزيل التكراري من نقاط القوة الأساسية في Wget |
| استخراج بيانات منظمة (جداول، قوائم، جهات اتصال) | Thunderbit | Wget يعطيك HTML خام فقط — وما زلت تحتاج إلى تحليله. Thunderbit يقرأ الصفحة بالذكاء الاصطناعي ويخرج البيانات بشكل منظم إلى Excel أو Google Sheets أو Airtable أو Notion من غير كتابة أي كود. كما أن الاستخراج السحابي يتعامل مع تدوير الـ IP ومكافحة البوتات، فلا تحتاج إلى إعداد بروكسي أصلًا. |
| تنفيذ طلبات REST API عبر بروكسي | curl | تحكم أفضل في الترويسات، ودعم أصلي لـ JSON، ودعم SOCKS5 |
| جمع بيانات مجدولة بشكل مستمر | Thunderbit Scheduled Scraper أو cron + wget | Thunderbit يتكيف عند تغيّر تخطيطات الصفحات؛ أما سكربتات cron + wget فتتعطل بصمت |
Wget ممتاز في تنزيل الملفات. لكن سير العمل من نوع "اضبط بروكسي → دوّر IPs → نزّل HTML → اكتب محللًا → صدّر إلى جدول" فيه أجزاء كثيرة متحركة، خصوصًا لما يكون المطلوب في النهاية مجرد جدول بيانات. إذا كان هذا يذكرك بشيء، فـ إضافة Chrome الخاصة بنا تتولى كامل العملية في نقرتين فقط. ولمعرفة المزيد عن هذا النهج، اطلع على أدلتنا حول استخراج الويب بالذكاء الاصطناعي واستخراج البيانات من الويب من دون برمجة.
أما إذا كان هدفك هو "تنزيل ملف ZIP هذا عبر بروكسي مؤسسي" — فـ Wget ما يزال هو الأداة المناسبة، والآن تعرف كيف تضبطه بشكل صحيح.
أهم الخلاصات
الخلاصة السريعة:
- أربع طرق مع أولوية واضحة: وسائط CLI تتغلب على إعدادات المستخدم، والتي تتغلب على إعدادات النظام، والتي تتغلب على متغيرات البيئة. و
--no-proxyيتجاوز الجميع. - استخدم الأحرف الصغيرة دائمًا لمتغيرات البيئة (
http_proxyوليسHTTP_PROXY). فالأحرف الكبيرة تُهمل بصمت. - أضف دائمًا
http://إلى عنوان البروكسي، حتى معhttps_proxy. فوجهة البروكسي نفسها HTTP، وهي تمرر HTTPS عبر CONNECT. - استخدم
onللقيم المنطقية داخل.wgetrcووسائط-e. فهو الخيار الأكثر أمانًا عبر مختلف الإصدارات. - مستخدمو Windows: استخدموا
--config=C:\path\to\wgetrcلتفادي الغموض في ملفات الإعدادات. واستخدمواsetفي CMD أو$env:في PowerShell لمتغيرات البروكسي الخاصة بالجلسة. - مستخدمو بروكسيات الشركات: Wget لا يستطيع قراءة ملفات PAC، ولا يدعم NTLM بشكل أصلي. استخدم Cntlm كوسيط محلي عند الحاجة.
- احفظ ورقة الغش فوق — ستوفر عليك تعيد قراءة المقال كل مرة تنسى فيها اسم وسيط ما.
إذا كان هدفك الحقيقي هو استخراج بيانات منظمة، فقد يكون Thunderbit أو curl خيارًا أنسب. أفضل جلسة استكشاف أخطاء هي اللي ما تضطر تبدأها أصلًا.
الأسئلة الشائعة
1. هل يدعم Wget بروكسيات SOCKS5؟
لا. يدعم GNU Wget 1.x فقط بروكسيات HTTP وHTTPS وFTP. مشروع Wget2 لديه طلب ميزة لـ SOCKS5، لكنه ليس خيارًا موثقًا قياسيًا. وإذا أردت SOCKS5، فاستخدم curl مع صيغ socks5:// أو socks5h:// الأصلية، أو شغل Wget عبر proxychains4 لفرض التوجيه عبر SOCKS.
2. لماذا يتم تجاهل إعداد البروكسي عندما أستخدم HTTP_PROXY بالأحرف الكبيرة؟
Wget يقرأ فقط أسماء متغيرات البيئة المكتوبة بحروف صغيرة (http_proxy وhttps_proxy وftp_proxy وno_proxy). أما النسخ المكتوبة بأحرف كبيرة مثل HTTP_PROXY فيتم تجاهلها بصمت — بلا خطأ ولا تحذير. وهذه من أكثر المشاكل شيوعًا وإزعاجًا لأنك ما تشوف أي إشارة أصلًا إلى وجود مشكلة. استخدم الأحرف الصغيرة دائمًا.
3. كيف أتجاوز البروكسي لنطاقات معينة؟
استخدم التعليمات no_proxy، سواء كمتغير بيئة أو داخل .wgetrc:
export no_proxy=localhost,127.0.0.1,.mycompany.com
أو في ~/.wgetrc:
no_proxy = localhost,127.0.0.1,.mycompany.com
النطاقات تُفصل بفواصل. والنقطة في البداية (.mycompany.com) تشمل كل النطاقات الفرعية.
4. هل يمكنني استخدام Wget مع بروكسيات متناوبة؟
Wget نفسه ما فيه تدوير بروكسي مدمج. عندك خيارين: إما تستخدم مزود بروكسي يدوّر عناوين IP من جهة الخادم (بحيث تتصل دائمًا بالبوابة نفسها لكن عنوان الخروج يتغير)، أو تكتب سكربت shell يختار بروكسيًا عشوائيًا من قائمة ويمرره عبر -e http_proxy=... في كل تشغيل. ولأي شيء أعقد من هذا — مثل التدوير التلقائي أو منطق إعادة المحاولة أو التعامل مع الحماية من البوتات — غالبًا أداة استخراج متخصصة تكون أفضل.
5. ما الفرق بين http_proxy وhttps_proxy في Wget؟
يُستخدم http_proxy عندما يبدأ عنوان URL المستهدف بـ http://. ويُستخدم https_proxy عندما يكون العنوان https://. وفي كلتا الحالتين، يكون عنوان البروكسي نفسه عادةً http://. بالنسبة لوجهات HTTPS، يرسل Wget طلب HTTP CONNECT عبر البروكسي لإنشاء نفق، ثم تتم عملية التشفير HTTPS فعليًا من الطرف إلى الطرف بين Wget والخادم المستهدف. البروكسي يرى اسم المضيف فقط (من طلب CONNECT) لكنه لا يستطيع قراءة البيانات المشفرة.
جرّب Thunderbit لاستخراج الويب بالذكاء الاصطناعي Get Started Free
اعرف المزيد
