A .rex domain won't resolve
The symptom is the browser saying it cannot find the server — not a certificate warning, not a 502. Nothing answered the name.
Start here:
rex doctorIt checks the resolver file, whether rexenv’s DNS is answering, and whether something else has taken the TLD over — which is the cause more often than a broken rexenv.
Check the resolver file exists
Section titled “Check the resolver file exists”cat /etc/resolver/rexIt should name a nameserver on 127.0.0.1 and port 15353. If the file is missing, macOS is
not asking rexenv about .rex at all — reinstall it from Settings, which re-runs the admin
prompt from first run.
Check the DNS server is answering
Section titled “Check the DNS server is answering”dig @127.0.0.1 -p 15353 myshop.rexAn answer of 127.0.0.1 means DNS is fine and the problem is further along — check that the
services are running with rex status.
No answer means the DNS agent is not running. It normally survives quitting the app and restarts itself, so this is worth reporting.
Another tool has taken the TLD
Section titled “Another tool has taken the TLD”If you also have Valet, Herd, dnsmasq or a similar tool installed, more than one thing may be
writing /etc/resolver files. rex doctor calls this out specifically, because the failure is
confusing: the file exists, it just points somewhere else.
macOS caching
Section titled “macOS caching”macOS caches negative DNS answers. If you fixed the cause and the name still will not resolve:
sudo dscacheutil -flushcache && sudo killall -HUP mDNSResponderIt resolves in the terminal but not in the browser
Section titled “It resolves in the terminal but not in the browser”Chrome and Firefox can be configured to use DNS-over-HTTPS, which bypasses the system resolver
and therefore bypasses /etc/resolver entirely. Turning off “Secure DNS” for the browser, or
adding an exception, fixes it.
Safari uses the system resolver and is a useful control: if the site loads there but not in Chrome, this is why.