ຄຳຮ້ອງ HTTPS ທຳມະດາຂອງແອັບ iOS ສາມາດປາກົດໃນ debugging proxy ໃນຂະນະທີ່ທຣາຟຟິກ WebSocket ຂອງມັນຫາຍໄປ. ກຳນົດການຂົນສົ່ງ WebSocket ກ່ອນ: URLSessionWebSocketTask ສາມາດໃຊ້ການຕັ້ງຄ່າ proxy ລະດັບ session, ໃນຂະນະທີ່ຫ້ອງສະໝຸດທີ່ເປີດ socket ຂອງຕົນເອງຕ້ອງການການເຊື່ອມໂຍງທີ່ຮອງຮັບຂອງຕົນເອງ. ສຳລັບການເຊື່ອມຕໍ່ Network.framework ດິບໃນ iOS 17+, ຕັ້ງຄ່າ ບໍລິບົດ proxy ຂອງ NWConnection ເອງ.

ໃນ iOS 17 ຫຼືສູງກວ່າ, ສ້າງ session ດ້ວຍ SOCKSv5 proxy ທີ່ຊັດເຈນ:

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 listener ທີ່ເຂົ້າເຖິງໄດ້ຂອງ debugging proxy ທີ່ມີຢູ່. ເປີດ listener ນັ້ນໃນແອັບ proxy. HTTP listener ຂອງມັນສາມາດຢູ່ໃນພອດອື່ນ.

ສ້າງ webSocketTask ຈາກ session ທີ່ສົ່ງຄືນ. ວຽກທີ່ສ້າງຜ່ານ URLSession ອື່ນບໍ່ໄດ້ຮັບການແທນທີ່ຂອງ session ນີ້. ອາເຣ proxyConfigurations ຫວ່າງເປົ່າໃຊ້ຄ່າເລີ່ມຕົ້ນຂອງລະບົບ; ມັນບໍ່ແມ່ນການເລືອກເສັ້ນທາງຊື່ທີ່ຊັດເຈນ.

ການເຂົ້າເຖິງ ແລະ ຂໍ້ຄວາມທີ່ອ່ານໄດ້ ແມ່ນໝາກຫີນຄົນລະກ້ອນ

ໂທລະສັບຈິງຕ້ອງການທີ່ຢູ່ທີ່ເຂົ້າເຖິງຄອມພິວເຕີ debugging. ໃນໂທລະສັບນັ້ນ, 127.0.0.1 ໝາຍເຖິງໂທລະສັບເອງ. ກວດສອບອິນເຕີເຟສຂອງ listener ແລະ ການເຂົ້າເຖິງລູກຄ້າທີ່ proxy ອະນຸຍາດ ເມື່ອການເຊື່ອມຕໍ່ບໍ່ເຄີຍໄປຮອດບ່ອນນັ້ນ.

ເສັ້ນທາງ SOCKS ຂົນສົ່ງການເຊື່ອມຕໍ່. ການອ່ານເນື້ອຫາ wss ຕ້ອງການເພີ່ມເຕີມການຕັ້ງຄ່າກວດສອບ TLS ຂອງເຄື່ອງມື debugging ແລະ ຄວາມໄວ້ໃຈທີ່ເໝາະສົມໃນອຸປະກອນ. ການປັກໝຸດໃບຮັບຮອງ ຫຼື ການຈັດຕັ້ງ TLS ແຍກຕ່າງຫາກ ສາມາດຂັດຂວາງການກວດສອບນັ້ນໄດ້ ເຖິງແມ່ນວ່າທຣາຟຟິກໄປຮອດ listener.

ຊອກຫາການແລກປ່ຽນ WebSocket ແລະ ຂໍ້ຄວາມຫຼັງຈາກການເຊື່ອມຕໍ່ຖືກສ້າງຂຶ້ນ. ການເຫັນພຽງຄຳຮ້ອງ polling ດຽວຈາກແອັບ Socket.IO ບໍ່ແມ່ນຫຼັກຖານວ່າການຂົນສົ່ງ WebSocket ຕໍ່ມາຂອງມັນໃຊ້ເສັ້ນທາງດຽວກັນ. ຮັກສາການຕັ້ງຄ່າ debugging ທີ່ຊັດເຈນນີ້ໄວ້ພາຍໃນສະພາບແວດລ້ອມພັດທະນາທີ່ແອັບຕັ້ງໃຈໄວ້.

ບົດຄວາມທີ່ກ່ຽວຂ້ອງ