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 यातायातले उही मार्ग प्रयोग गर्‍यो भन्ने प्रमाण होइन। यो स्पष्ट डिबगिङ कन्फिगरेसनलाई एपको अभिप्रेत विकास वातावरणभित्र राख्नुहोस्।

सम्बन्धित लेखहरू