iOS अ‍ॅपच्या नेहमीच्या HTTPS विनंत्या डीबगिंग प्रॉक्सीमध्ये दिसू शकतात, पण त्याचा WebSocket रहदारी दिसत नाही. आधी WebSocket वाहतूक ओळखा: URLSessionWebSocketTask सत्र-स्तरीय प्रॉक्सी कॉन्फिगरेशन वापरू शकतो, तर स्वतःचे सॉकेट उघडणाऱ्या लायब्ररीला स्वतःचे समर्थित एकत्रीकरण लागते. iOS 17+ वर कच्च्या Network.framework कनेक्शनसाठी 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 वाहतूक त्याच मार्गाने गेली. हे स्पष्ट डीबगिंग कॉन्फिगरेशन अ‍ॅपच्या इच्छित विकास वातावरणात ठेवा.

संबंधित लेख