[BUG][iOS] TUN forwards only port 443 — connections to other ports (Telegram 80/5222, Ookla 8080) are silently dropped and never reach the server

[zebrr]

Environment

• Karing 1.2.24.2709 (iOS)
• iOS 26.6.1, iPhone — also reproduced on the previous version
• TUN enabled, rule mode, [Proxy Traffic] Resolve Channel = FakeIP (defaults, unchanged for months)
• Single manually added outbound (not a subscription): VLESS + REALITY + XHTTP, server port 47002
• Server: self-hosted Xray 26.3.27, no routing rules at all ("routing": null, one freedom outbound)

Summary

On iOS, only connections to destination port 443 leave the tunnel. Connections to any other destination port never reach the proxy server — they are dropped silently inside Karing, with no entry in the server access log and no error in any log on either side.

Practical impact: Telegram never connects (MTProto uses 443/80/5222 to bare DC IPs), Ookla Speedtest never runs a measurement (test servers are on 8080), and the Roborock app loads its HTTPS API but cannot reach the vacuum or load the map (device channel is not on 443).

Reproduction

1. Karing on iOS with the setup above, connected.
2. Run this scenario: YouTube 60 s → Ookla Speedtest (full run) → Telegram 60 s → Roborock 30 s.
3. Read the proxy server's access log for that window.

Result — 93 seconds, 69 connections, 37 unique destinations:

port 443    69
port 80      0
port 5222    0
port 8080    0

Telegram DC (91.108./149.154./185.76.151.)     0
Ookla test servers (:8080)                     0
YouTube                                       15   OK
Roborock / Xiaomi                             10   HTTPS API only, all on :443

Roborock is the clearest case — the app breaks partially. Its HTTPS endpoints go through:

api-ru.roborock.com:443
ruiot.roborock.com:443
wood-ru.roborock.com:443
ksyru0-eco.fds.api.xiaomi.com:443
roborocklimited.zendesk.com:443

…so the app opens and shows the account, but the device channel never connects and the map never loads.

Controls

1. Same link in a different client, same phone, 90 seconds later. The identical outbound link was imported into another iOS client (Happ, xray-core) and the same scenario was repeated:

                        Karing        other client
connections                 69                 149
unique destinations         37                  62

port 443                    69                 114
port 80                      0                  12
port 5222                    0                  12
port 8080                    0                  11

Telegram DC                  0                  37
Ookla test servers           0                  11

Telegram, Speedtest, YouTube and Roborock all work. This excludes the server, the link, the protocol and the network path.

2. Second iPhone. Another iPhone with the same Karing version, same settings and the same link works normally — Telegram, Speedtest and Roborock all fine.

3. Already tried, no change: reinstalling Karing; Reset cache and Reset network inside Karing; removing every other VPN profile from iOS; switching rule → global mode; four different servers (three providers, two countries, direct and via relay).

4. Other platforms. The same Karing account and the same servers work correctly on macOS and Windows.

Expected

Connections to destination ports other than 443 are forwarded to the outbound like any other traffic.

Actual

They never leave the device. The server sees nothing, and neither side logs an error.

Possibly related

#1845 — macOS: non-TLS TCP payload to ports 443/5222 is silently black-holed. Same shape of failure (TLS fine, everything else silently swallowed, nothing in the logs), reported for macOS.

[GooRingX]

enble 'debug log' and upload service_core.log

[zebrr]

Debug log enabled, scenario reproduced on the affected iPhone on 2026-09-08 at ~11:15 (+03:00): Telegram, then the Roborock app. Attached.

service_core.anonymized.json
service_core.anonymized.log

• full log since 2026-09-07 02:47; the reproduction with debug log is the block from 2026-09-08 11:15:03 (line 633) to the end.
• the config that was in effect.

Both files are anonymized with consistent substitutions: outbound tags → NODE-A…D, server IP → 203.0.113.14, REALITY SNI → www.example.edu, UUID / keys / passwords → random values of the same format, Wi-Fi SSID/BSSID → placeholders. Everything else, including all destination addresses, is verbatim; line numbers are unchanged.

What the log shows: every connection that enters through tun_in stops right after the sniff rule matches. There is no sniffed protocol line, no final rule match and no outbound for any of them, on any port, 443 included. Lines 1620–1625:

+0300 2026-09-08 11:15:59 [11617] [0] DEBUG route.go:612 router: [inbound:tun_in,destination domain:,destination ip:95.161.76.100:80] matchRule inbound=tun_in => sniff
+0300 2026-09-08 11:15:59 [11617] [0] DEBUG route.go:612 router: [inbound:tun_in,destination domain:,destination ip:95.161.76.100:5222] matchRule inbound=tun_in => sniff
+0300 2026-09-08 11:15:59 [11617] [0] DEBUG route.go:612 router: [inbound:tun_in,destination domain:,destination ip:149.154.167.50:443] matchRule inbound=tun_in => sniff
+0300 2026-09-08 11:15:59 [11617] [0] DEBUG route.go:612 router: [inbound:tun_in,destination domain:,destination ip:149.154.167.50:80] matchRule inbound=tun_in => sniff
+0300 2026-09-08 11:15:59 [11617] [0] DEBUG route.go:612 router: [inbound:tun_in,destination domain:,destination ip:95.161.76.100:443] matchRule inbound=tun_in => sniff
+0300 2026-09-08 11:15:59 [11617] [0] DEBUG route.go:612 router: [inbound:tun_in,destination domain:,destination ip:149.154.167.50:5222] matchRule inbound=tun_in => sniff

There are 23 such tun_in lines in the log (22 to Telegram DCs 149.154.x.x / 95.161.76.100 on 443/80/5222, one to Apple push on 443) and zero follow-ups for any of them. Meanwhile all 92 connections that did get routed came in through mixed_in_rule from 127.0.0.1, i.e. via the HTTP proxy attached to the VPN, and each of those goes through the full chain: sniffed protocol: tls → matchRule final → outbound/vless[NODE-D-XHTTP-47002] → XHTTP is dialing. Example: lines 1626–1633 (the Roborock app's HTTPS call).

So "only port 443" in my report is the symptom, not the mechanism: apps that honour the system HTTP proxy (HTTPS via URLSession) work through the proxy inbound; anything that uses raw sockets through the TUN (Telegram MTProto on any port, Ookla, the Roborock device channel) never gets past the sniff step. That also matches the server-side count from the report: 69 connections, all on 443, exactly what the proxy forwards via CONNECT. On the second iPhone with the same Karing version and the same config the TUN path works.

Side note: the 2026-09-07 part of the log contains 47 entries service/oom-killer[0]: memory pressure: critical, usage: 40 MiB, resetting network; none during the reproduction on 09-08.

[GooRingX]

If no "reject" logs appear, then it is not being blocked by the VPN.Try a different VPN.

[zebrr]

Found it: TUN -> Route Exclusion -> Hide VPN Icon.

With it ON, Karing injects two entries into the tun inbound:

"route_exclude_address": ["0.0.0.0/31", "::/127", "10.20.0.1/30"]

With it OFF, the same device generates ["10.20.0.1/30"] — byte-for-byte what the working iPhone had all along. The user setting tun.route_exclude_address is empty on both devices; Karing adds these itself. Excluding a prefix starting at 0.0.0.0 removes the default route, so iOS hands nothing to the tunnel: zero accepted connections in the log I uploaded, not even DNS, against 162 on the working phone. Everything that still worked went through the HTTP proxy you attach to the VPN, applied by iOS independently of routes. That is the whole "only port 443" — proxy CONNECT. Telegram, Ookla and Roborock use raw sockets, so they died.

Option off, Telegram works. Nothing else changed.

Correcting myself: the connections are never accepted at all, not "stopped at sniff"; and the oom-killer lines are noise.

So: not the VPN, not the server, not the network. Your config generator.

The only hint under this toggle is "Enabling IPv6 will cause this function to fail". Nothing says it disables tunnel routing and leaves you with a proxy while the app still shows "connected" — no warning, no error, no log line. Add a warning, and retitle this issue please.

[GooRingX]

https://github.com/KaringX/karing/releases/tag/v1.2.25.2800