On macOS, you might be able to use /etc/resolver to fix this:

  sudo sh -c 'echo "nameserver 192.168.1.1" > /etc/resolver/captive.apple.com'

I did this for an internal website at my university that could only be resolved using the network name server. It just occurred to me that it might also work for the URL macOS uses to detect captive portals. We'll have to see if it works the next time I'm at a café.

I think what may happen with this is:

Captive.apple.com resolves to captive portal domain

Captive portal domain fails to resolve because the portal is private and Google DNS doesn’t know about it.

Might work for captive portals that Google can resolve though?

prefer this form:

    echo "nameserver 192.168.1.1" | sudo tee /etc/resolver/captive.apple.com

For macOS and iOS, you can create a profile to configure which DNS server you want to use at all times (including across different Wi-Fi networks and mobile data). See:

https://doh.lvv.me/

That’s what I’ve been using for years and never had any issues with public hotspots.

I want the DNS to resolve the captive portal when it needs too.

I think if I force the dns this way, the public dns won’t resolve the captive portal.

When the internet is cut, it needs to use the network’s dns to resolve the captive portal domain (whatever that is)

I've seen some routers that will just silently redirect anything on port 53 to their own idea of the best dns server to use. That would probably "fix" this problem, but I always thought it was a little shady to redirect stuff like that. Makes troubleshooting problems difficult if you don't know it is happening.

Just put an IP address into your address bar. They're usually intercepting all port 80 traffic.

this only works if the captive portal's domain is also in the public dns.

Some captive portals are only accessible in the private network.