Hi,
Since iOS 26 (and any other apple system with a 26 version) there is a very weird behavior in the whole apple ecosystem (iOS, iPadOS, macOS and visionOS).
I'm self-hosting a web project called mempool (https://github.com/Retropex/mempool). This project is entirely self-hosted on my own infrastructure, so I have advanced control to be sure it's just not an anti-DDoS feature that makes the bug happen. So the bug is once I visit my website, for example this page (https://mempool.guide/tx/d86192252a6631831e55f814aea901e65407b6dbda77e1abdea8ec27861e9682) the OS will lose the ability to connect to the underlying IP of the domain (mempool.guide) but the issue seems to affect only the HTTPS/HTTP port (443/80). The issue is system wide, not only is Safari. For exemple I have another domain that resolve to the same IP (haf.ovh) and if this link above trigger the bug then I will also lose the ability to connect to https://haf.ovh
A temporary fix that I have is that if I turn off wifi/cellular then I turn it on again I can connect again to my server again until the bug is triggered again.
I have done test with tcpdump on my server and the connection isn't making it to my server that's why I think it's an OS issue, especially given the fix above.
This issue can be reproduced on any apple device out of the box with a system with >v26.
All device (Mac, iPad, iPhone, vision) with version pre-26 are completely unaffected by the bug and can freely explore the website without loosing the connection
macOS is less affected by this bug, it can be random with it. With iOS/iPadOS it's systematic.
Another thing to note is that the same URL on firefox/chrome for iOS doesn't trigger the bug.
Let me know if anyone has an idea on what's going on. Thanks, Léo.
I'm self-hosting a web project called mempool (https://github.com/Retropex/mempool). This project is entirely self-hosted on my own infrastructure, so I have advanced control to be sure it's just not an anti-DDoS feature that makes the bug happen.
If you haven't already, please do the following:
-
You can do the testing below on any machine you can reproduce the issue on. I'd probably use a Mac, but you can use iOS if that's simpler. However, with whatever machine you’re testing with, try and use the most "minimal" system possible. Ideally, that's a device that's just been reset, but using a newly created account works reasonably well on macOS as long as there isn't too much 3rd party software running system-wide. The key here is that having "less" on the machine minimizes the risk of private data leaking and extraneous log "noise".
-
I'd recommend installing the "mDNSResponder" and "Network Diagnostics" on the device. Those might not be necessary, but both of those increase the level of network diagnostic data, and installing them "now" makes it more likely that the engineering team will have exactly the information they need.
-
Once you've got the profile installed, turn the device completely off and leave it alone for “a while" (the longer the better). The goal here is to both reset the device (so the test is as "clean" as possible) and create a long "gap" in the system log (so it's easier to differentiate between system runs). A few minutes is fine, but an hour or so is even better.
-
Turn the device on, fully unlock it, "prep" the machine for your test (launch Safari, etc.), then wait a minute or two. The goal here is to allow any other system activity to "settle" before you start actually testing.
-
Reproduce the issue, noting the time you start testing and the time the problem occurs (down to the second if possible). The console log volume is ENORMOUS, so knowing "when" to look is hugely helpful.
-
Once you've reproduced the problem, leave the machine alone for a minute or two to let the log "settle", then trigger a sysdiagnose using the instructions for either of the configuration profiles above.
Once you've got that sysdiagnose, please file a bug, upload your sysdiagnose, and then post the bug number back here.
__
Kevin Elliott
DTS Engineer, CoreOS/Hardware
