توجيه WebSocket في URLSession عبر SOCKS5 على iOS 17+

قد تظهر طلبات HTTPS العادية لتطبيق iOS في وكيل تصحيح بينما تكون حركة WebSocket مفقودة. حدِّد ناقل WebSocket أولاً: يمكن لـ URLSessionWebSocketTask استخدام إعداد وكيل على مستوى الجلسة، بينما تحتاج مكتبة تفتح مقابسها الخاصة إلى تكامل مدعوم خاص بها. لاتصال Network.framework خام على iOS 17+، اضبط سياق الوكيل الخاص بـ NWConnection.

في iOS 17 أو أحدث، أنشئ الجلسة بوكيل SOCKSv5 صريح:

import Foundation
import Network

@available(iOS 17.0, *)
func makeDebugSession() -> URLSession {
    let configuration = URLSessionConfiguration.default
    let endpoint = NWEndpoint.hostPort(
        host: "192.0.2.10", port: 8889)
    configuration.proxyConfigurations = [
        ProxyConfiguration(socksv5Proxy: endpoint)
    ]
    return URLSession(configuration: configuration)
}

استبدل عنوان التوثيق ومنفذه بمستمع SOCKS القابل للوصول في وكيل التصحيح الحالي. فعِّل ذلك المستمع في تطبيق الوكيل. يمكن أن يكون مستمع HTTP الخاص به على منفذ آخر.

أنشئ webSocketTask من الجلسة المُعادة. المهمة التي تُنشأ عبر URLSession أخرى لا ترث تجاوز هذه الجلسة. مصفوفة proxyConfigurations الفارغة تستخدم إعدادات النظام الافتراضية؛ وهي ليست اختياراً صريحاً للمسار المباشر.

الوصول والرسائل القابلة للقراءة مرحلتان منفصلتان

يحتاج الهاتف الفعلي إلى عنوان يصل إلى حاسوب التصحيح. على ذلك الهاتف، يشير 127.0.0.1 إلى الهاتف نفسه. افحص واجهة المستمع ووصول العملاء المسموح به في الوكيل عندما لا يصل الاتصال إليه أبداً.

المسار عبر SOCKS يحمل الاتصال. وقراءة محتوى wss تتطلب إضافةً إلى ذلك إعداد فحص TLS في أداة التصحيح وثقة مناسبة على الجهاز. يمكن لتثبيت الشهادات أو تنفيذ TLS منفصل أن يمنع ذلك الفحص حتى عندما يصل المرور إلى المستمع.

ابحث عن تبادل WebSocket والرسائل بعد تأسيس الاتصال. رؤية طلب استطلاع واحد فقط من تطبيق Socket.IO ليست دليلاً على أن ناقل WebSocket اللاحق استخدم المسار نفسه. أبقِ إعداد التصحيح الصريح هذا ضمن بيئة التطوير المقصودة للتطبيق.