An alternative I use is http://captive.apple.com (other OS vendors have their own). Which may have a higher chance of being detected by the portal (more likely to be white-listed) and triggering the prompt correctly.
Frustratingly it doesn’t always work that way - one I have seen that is just bizarre is Qantas inflight wifi. It actually allows captive.apple.com to bypass the captive portal, so your iPhone, iPad or Mac thinks it has internet access. So you try to navigate to a page or use an app and just hit HTTPS certificate errors! So you have to think of some other site that is only HTTP or get the information card and enter the address it tells you to log in!
It’s crazy, because somebody must have had to configure something to explicitly let that through (not understanding the purpose of it?) and it just completely breaks it! I’ve tried to leave feedback (there is a link from the portal page) that they’ve screwed it up but it hadn't been fixed the last flight I went on..
It might be forging responses from captive.apple.com and not actually sending those out to the internet. If you set up your own intercept that responds 'Success', iOS will assume it has internet as well.
Like the sibling post said, you're probably seeing certificate errors caused by the portal, not traffic being allowed to captive.apple.com.
With http, a captive portal system will intercept your connection and redirect you to the portal authentication page. Most modern devices deal with it automatically by checking those plain http urls when the network comes up. For example, I think the way it works on iOS is that when you connect to a WiFi network the OS tries to hit http://captive.apple.com which triggers the redirect and prompts you for authentication.
With https, there's no way to have a valid TLS certificate for a random site the user is connecting to (ex: captive.apple.com), so you get a TLS error if you're attempting to connect to an https site while the portal is trying to redirect you for authentication.
