تطبيق يتجاهل البروكسي: ٤ طرق لتوجيه حركة المرور الخاصة به في ٢٠٢٦

```html

لقد قمت بتكوين البروكسي في إعدادات Windows، وأعدت تشغيل البرنامج - لكنه لا يزال يستخدم عنوان IP المنزلي. أو العكس: المتصفح يعمل بشكل صحيح عبر البروكسي، بينما يستمر عميل سطح المكتب بجانبه في عرض العنوان الحقيقي. هذه ليست مشكلة في البروكسي أو بيانات الاعتماد غير الصحيحة. هذه خاصية أساسية لكيفية تعامل أنظمة التشغيل مع "البروكسي النظامي": فهو لا يجبر، بل يقدم فقط.

فيما يلي أربع طرق فعالة لجعل تطبيق معين يعمل عبر SOCKS5، مع قيود كل منها والعقبات التي غالبًا ما تؤدي إلى فشل الإعداد.

لماذا لا يعمل البروكسي النظامي: الحقيقة التقنية القصيرة

لا يوجد في Windows بروكسي "نظامي" واحد. هناك على الأقل مجموعتان مستقلتان من الإعدادات. الأولى - WinINET: ما تقوم بتعديله في "الإعدادات → الشبكة والإنترنت → بروكسي". يتم قراءته بواسطة Internet Explorer/Edge، وبعض التطبيقات على .NET، وكل ما يستخدم مجموعة HTTP القياسية. الثانية - WinHTTP، التي تستخدمها خدمات النظام والعمليات الخلفية. وهنا النقطة الأساسية: WinHTTP لا يستخدم إعدادات WinINET، إلا إذا قمت باستيرادها صراحة. يتم ذلك باستخدام الأمر netsh winhttp import proxy source=ie، وتفصيل مهم من وثائق Microsoft - يأخذ الأمر لقطة للإعدادات الحالية. هل قمت بتغيير البروكسي في الإعدادات لاحقًا؟ اللقطة لن تتحدث تلقائيًا، يجب تنفيذ الأمر مرة أخرى.

لكن حتى الاستيراد لا ينقذك من الفئة الرئيسية من المشاكل. عدد هائل من البرامج لا تسأل النظام على الإطلاق: فهي تستخدم مجموعة الشبكة الخاصة بها وتفتح مقابس TCP مباشرة. هكذا تعمل العديد من عملاء سطح المكتب لوسائل التواصل الاجتماعي والمراسلات، مشغلات الألعاب، التورنت، وبعض تطبيقات Electron ذات التكوين المدمج، وأدوات Go وRust المجمعة. بالنسبة لهم، فإن سطر "البروكسي" في إعدادات النظام ببساطة لا يوجد كمفهوم.

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

الخطوة 0: تأكد من أن المشكلة هنا

1. قم بتشغيل التطبيق وانظر أي IP يظهر (ملف تعريف الحساب، صفحة الخدمة، أي مؤشر مدمج).
2. في الوقت نفسه، افتح المتصفح عبر نفس البروكسي وقارن العنوان. عناوين IP مختلفة = التطبيق يتجاهل الإعدادات النظامية.
3. تحقق مما إذا كان لدى البرنامج إعدادات بروكسي خاصة - غالبًا ما تكون مخفية في "الشبكة"، "الاتصال" أو في ملف التكوين. الدعم الأصلي دائمًا أفضل من الالتقاط الخارجي: طبقات أقل، أعطال أقل.
4. تحقق بشكل منفصل من DNS. إذا كان التطبيق يحل الأسماء محليًا، بينما تذهب حركة المرور عبر البروكسي، فإن مزود الخدمة الحقيقي الخاص بك لا يزال يرى إلى أين تذهب.

الطريقة 1. Proxifier - المعيار التجاري لـ Windows و macOS

يقوم Proxifier بالتقاط اتصالات التطبيقات وتحويلها إلى البروكسي المحدد وفقًا للقواعد: يمكنك تحديد "هذا exe - عبر البروكسي A، ذلك - عبر البروكسي B، الباقي - مباشرة"، تقسيمها حسب المنافذ والعناوين الوجهة، وبناء سلسلة من عدة بروكسيات.

الإصدارات الحالية في وقت كتابة هذا النص: 4.14 لـ Windows (إصدار 23 أبريل 2025) و 3.15 لـ macOS (18 سبتمبر 2025). الترخيص - $39.95 لكل نسخة، شراء لمرة واحدة، غير محدد بمدة، مع تحديثات ثانوية مجانية؛ هناك تجربة كاملة الوظائف لمدة 31 يومًا، وخصومات بالجملة من نسختين واسترداد خلال 30 يومًا.

ممارسة الإعداد:

1. خوادم البروكسي → إضافة: حدد العنوان، المنفذ، بروتوكول SOCKS5 وبيانات الاعتماد. اضغط على Check - يجب أن ينجح الاختبار قبل إنشاء القواعد، وإلا ستقوم بتصحيح مشكلتين في وقت واحد.
2. قواعد Proxification → إضافة: في التطبيقات، اختر الملف التنفيذي المحدد، في الإجراء - بروكسيك.
3. اترك القاعدة الافتراضية مباشر، إذا كنت لا تريد توجيه كل الجهاز. هذه هي الخطأ الأكثر شيوعًا بين المبتدئين: الافتراضي → بروكسي يضع في النفق كل من تحديث النظام ومضاد الفيروسات، وحركة المرور الزائدة التي تدفع مقابلها بالجيجابايت.
4. راقب علامة التبويب Connections في الوقت الحقيقي: هناك يمكنك رؤية أي اتصال ذهب عبر البروكسي، وأي اتصال ذهب مباشرة.

نقاط القوة - النضج، القواعد المستقرة والتشخيص الواضح. نقاط الضعف - التكلفة وأنه في الأنظمة المضادة للغش العدوانية، قد يتم ملاحظة الالتقاط عبر السائق.

الطريقة 2. ProxiFyre - بديل مجاني لـ Windows مع دعم UDP

إذا كانت الميزانية صفرية، والمنصة هي Windows، هناك مشروع مفتوح ProxiFyre (ترخيص AGPL-3.0). يعتمد على NDISAPI/Windows Packet Filter - أي أنه يعمل على مستوى سائق تصفية الحزم ويستطيع القيام بما ينقص غالبًا: توجيه ليس فقط TCP، ولكن أيضًا UDP لكل تطبيق على حدة. هذا أساسي لكل ما يعمل على UDP وQUIC - قنوات الصوت، عملاء الألعاب، وبعض اتصالات المتصفح الحديثة.

من المفيد في الإصدارات الحديثة: دعم IPv6 ظهر في v2.3.0، SOCKS5-over-TLS - في v2.4.0، هناك قواعد استثناء للتطبيقات وcatch-all لجميع الآخرين. المتطلبات: مثبت Windows Packet Filter، مكتبات وقت التشغيل لـ Visual Studio وحقوق المسؤول.

يتم الإعداد من خلال ملف تكوين مع قائمة التطبيقات ونقاط نهاية SOCKS5 المرتبطة بها. عتبة الدخول أعلى من Proxifier، لكنك لا تدفع وتحصل على UDP.

الطريقة 3. proxychains-ng - خيار سريع لـ Linux، مع ملاحظات

الكلاسيكية لأنظمة Unix: proxychains4 curl https://example.com. الآلية - LD_PRELOAD: المكتبة تستبدل استدعاءات المقابس في البرنامج المرتبط ديناميكيًا وتوجهها إلى SOCKS.

القيود التي يجب أن تعرفها قبل أن تبني عملية العمل على ذلك:

• فقط TCP. لا يتم توجيه UDP وICMP على الإطلاق - ping عبر proxychains لا يتحقق من أي شيء ذي معنى.
• فقط الثنائيات المرتبطة ديناميكيًا. الأدوات المجمعة بشكل ثابت (وهي حالة شائعة لـ Go) تتجاهل LD_PRELOAD بصمت - ستذهب الحركة مباشرة، ولن تلاحظ ذلك.
• على macOS، يتعارض مع SIP. حماية سلامة النظام تمنع تحميل المكتبة في الثنائيات النظامية: proxychains4 ssh user@host لن تعمل. الحل العملي هو نسخ الثنائي إلى دليلك الخاص (cp /usr/bin/ssh ~/.local/bin/) وتشغيل النسخة. لا أنصح بإيقاف SIP من أجل الراحة: أنت تضعف حماية النظام بالكامل من أجل أداة واحدة.

للمهام المحددة (curl، سكربت بايثون، أداة سطر الأوامر) تبقى proxychains أسرع طريقة - يتم تثبيتها بأمر واحد ولا تتطلب حقوق الجذر.

الطريقة 4. وضع TUN: الالتقاط على مستوى الواجهة الافتراضية

أكثر فئات الحلول شمولاً. يتم إنشاء واجهة شبكة افتراضية، ويتم توجيه مسارات النظام إليها، ويقوم مجموعة TCP/IP الخاصة بالمستخدم بتحليل الحزم وإخراجها عبر SOCKS5. هكذا تعمل tun2socks (تستخدم مجموعة gVisor، وتدعم TCP وUDP، ومتاحة على جميع المنصات) وsing-box في وضع TUN.

الميزة الرئيسية مقارنة بـ LD_PRELOAD: يتم التقاط كل شيء، بما في ذلك الثنائيات الثابتة والتطبيقات ذات مجموعة الشبكة الخاصة بها. لدى sing-box أيضًا توجيه حسب العمليات - الحقول process_name، process_path وprocess_path_regex، مما يوفر قواعد حقيقية لكل تطبيق؛ وفقًا للوثائق، يتم دعم ذلك على Linux وWindows وmacOS (على المنصات المحمولة، يتم تعيين القواعد حسب اسم الحزمة أو معرف الحزمة).

هناك فخين يقع فيهما تقريبًا الجميع:

1. حلقة التوجيه. إذا كانت كل الحركة تذهب إلى TUN، فإن الاتصال بخادم SOCKS5 نفسه يحاول الذهاب إلى TUN - يبدأ النفق في توجيه نفسه. يتم علاج ذلك عن طريق مسار استثناء واضح إلى IP البروكسي عبر الواجهة الفيزيائية. هذه مشكلة معروفة وتظهر بانتظام في تكوينات sing-box.
2. الحقوق. إنشاء واجهة TUN وتعديل جدول التوجيه يتطلب حقوق الجذر/المسؤول. على جهاز مؤسسي مع سياسات، قد يكون ذلك غير متاح.

على Linux، هناك أيضًا نهجان مرتبطان: redsocks - الالتقاط عبر قواعد iptables مع إعادة التوجيه إلى منفذ محلي (فقط Linux، يحتاج إلى جذر)، وsshuttle، الذي يرفع توجيهًا مشابهًا لـ VPN فوق وصول SSH العادي، متجاوزًا المشكلة الكلاسيكية "TCP فوق TCP".

ما الذي ينكسر في أغلب الأحيان

• تسرب DNS. حتى مع إعداد SOCKS5 بشكل صحيح، يمكن أن يقوم التطبيق بحل النطاقات محليًا. تحقق من أن الحل يذهب إلى جانب البروكسي، وليس إلى مزود الخدمة الخاص بك.
• تم اختيار SOCKS4 بدلاً من SOCKS5. SOCKS4 لا يدعم UDP على الإطلاق ولا يمكنه تمرير اسم النطاق في بعض التطبيقات. لالتقاط حركة المرور العشوائية، استخدم فقط SOCKS5 - لماذا فقط هكذا، تم شرحه بالتفصيل في المادة عن مبادئ عمل SOCKS5.
• بروكسي HTTP بدلاً من SOCKS. يمكن لبروكسي HTTP توجيه HTTP وعبر CONNECT - اتصالات TLS. لا يقوم بتوجيه حركة TCP العشوائية لعميل الألعاب أو المراسلات.
• قاعدة افتراضية على كل الحركة. عند توجيه كل الجهاز، تحرق حركة المرور من مجموعة السكن على التحديثات والبيانات.
• عدم وجود تحقق بعد الإعداد. تحقق دائمًا من عنوان IP الفعلي الصادر من التطبيق نفسه، وليس من المتصفح بجانبه.

ما نوع البروكسي الذي يجب استخدامه للاعتراض

تقنيًا، يعمل الاعتراض مع أي نقطة نهاية SOCKS5، لكن اختيار النوع يحدد ما إذا كانت سيناريوهاتك ستصل إلى النتيجة.

• السكنية - عندما يعمل التطبيق مع خدمة تقيم سمعة IP: وسائل التواصل الاجتماعي، الأسواق، لوحات الإعلانات، نماذج الدفع. يتم التعرف على عنوان مركز البيانات هناك تقريبًا على الفور. تناسب البروكسي السكنية مع دعم SOCKS5 وجلسات ثابتة - هذا أمر حاسم، لأن تغيير IP في منتصف جلسة نشطة يبدو أسوأ لمكافحة الاحتيال من IP "غريب" في البداية.
• مركز البيانات - لمهام تقنية بدون مكافحة احتيال صارمة: الوصول إلى API، الخدمات الداخلية، بيئات الاختبار، كل ما يهم فيه السرعة واستقرار القناة، وليس "مظهر" العنوان. هنا البروكسي من مركز البيانات يوفر أفضل ping وقابلية التنبؤ.
• المحمولة - عندما يكون التطبيق محمولًا بطبيعته (محاكي، عميل وسيلة التواصل الاجتماعي) ويتطلب أقصى ثقة من المنصة.

بشكل منفصل: الاعتراض على مستوى التطبيق - ليس VPN، ولا ينبغي استبدال أحدهما بالآخر. إذا كنت بحاجة إلى قناة واحدة مؤمنة لكل الجهاز، وليس عناوين IP مختلفة لبرامج مختلفة، هناك مقارنة للنهج في تحليل WireGuard مقابل البروكسي.

كيفية اختيار الطريقة في دقيقة واحدة

1. التطبيق لديه إعدادات بروكسي خاصة به → استخدمها، لا تعترض شيئًا.
2. Windows، تحتاج إلى نتيجة اليوم، الميزانية متاحة → Proxifier.
3. Windows، تحتاج إلى UDP ومجانًا → ProxiFyre.
4. Linux، مهمة لمرة واحدة مع أداة سطر الأوامر → proxychains-ng.
5. تحتاج إلى اعتراض ثنائي ثابت، لعبة أو كل شيء مع قواعد لكل تطبيق → وضع TUN (sing-box، tun2socks)، ولا تنسَ مسار الاستثناء إلى البروكسي.

الاستنتاج الرئيسي بسيط: "البروكسي لا يعمل" في تسع حالات من أصل عشر يعني "البروكسي تم إعداده على المستوى الخطأ". الإعداد النظامي هو طلب مهذب للتطبيق، بينما الاعتراض على مستوى السائق، LD_PRELOAD أو واجهة TUN - هو إجبار. اختر الطبقة بشكل صحيح، تحقق من عنوان IP الفعلي الصادر من التطبيق نفسه ولا تنسَ DNS - وستُحل المشكلة مرة واحدة، بدلاً من أن تظهر بعد كل تحديث للبرنامج.