د 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 لېږد یې ورته لاره کارولې ده. دا روښانه ډیبګینګ ترتیبات د اپلیکیشن په پام شوې پراختیایي چاپیریال کې وساتئ.

اړوندې مقالې