When one network works and another does not, the site is fine and the path is not. Three causes cover nearly all of it, and each can be told apart in a minute.

1. DNS that has not caught up

Your office resolver has the new record; the mobile carrier's resolver still has the old one. Nothing is broken - it is the TTL. See the domain still points at the old server.

dig +short yourdomain.com @8.8.8.8\ndig +short yourdomain.com @1.1.1.1

2. IPv6 that is half-configured

Mobile networks are heavily IPv6. Wifi often is not. An AAAA record pointing at a server that does not actually listen on IPv6 works everywhere except mobile data - which is exactly this symptom.

curl -6 -sS -o /dev/null -w 'v6 %{http_code}\n' https://yourdomain.com\ncurl -4 -sS -o /dev/null -w 'v4 %{http_code}\n' https://yourdomain.com
If the v6 line hangs or fails while v4 answers, that is your fault found. Fix the listener or remove the AAAA record - see IPv6 on a VPS.

3. An incomplete certificate chain

Desktop browsers often hold the intermediate certificate from an earlier site and fill the gap silently. A phone that has never seen it cannot, so the same site is untrusted on mobile and fine on the laptop.

openssl s_client -connect yourdomain.com:443 -servername yourdomain.com < /dev/null 2>/dev/null \\n  | grep -E '^ *[0-9] s:|Verify return code'

See an incomplete certificate chain. Serve fullchain.pem, never cert.pem.

Ruling the phone out

Turn wifi off, load the site, then turn on a VPN on the same phone. If it works through the VPN, the problem is the carrier path - DNS or IPv6 - and not your phone.