Somewhat, though various privacy enhancements have made / are making this harder and harder as time has gone on (which is generally good, because it also prevents your ISP / hotel from doing the same thing). Browsers are in a somewhat unique position, where they have detailed knowledge about every request they perform.
E.g. historically you could figure out IP <-> domain name pretty easily by simply watching DNS: cache the IP addresses for each domain as it's looked up, and do a reverse lookup when a request for that IP occurs. DNSSEC / DNS over HTTPS / etc hide that data, so it has to come from other sources (e.g. a remote lookup, bulk cached data, etc) or simply not be known at all.
You could also pull the data from the HTTPS handshake, which has Server Name Indication to support multiple domains behind a single IP address (e.g. hosted in a cloud), if that data exists (single-site static IPs may not have this). But Encrypted Client Hello hides this, so you're back to just IP addresses. (ECH is not very widespread yet AFAIK, but it's growing)
---
You can work around much of this if you have your router MITM your traffic, but that's kinda a pain to set up (as it should, it'd be very bad if someone else did it and you didn't notice), and essentially only works with "common" requests (e.g. https) which aren't using certificate pinning (a small number of mobile apps do this, outside that it's more rare AFAICT). You can just block all those of course, but it'll break some things.
You'd be looking for a "TLS / ECH downgrade attack", and... while a brief googling isn't finding anything saying explicitly "yea" or "nah", it sounds like it should generally be prevented. E.g. https://wiki.mozilla.org/Security/Encrypted_Client_Hello mentions explicit bypasses are possible with enterprise proxies (which generally require client-side certificate authorities which are an explicit opt-in to allowing a third party to decrypt your traffic). And it's a TLS 1.3 extension, and TLS 1.3 -> 1.2 downgrades are intentionally prevented as part of 1.3's design...
... and even if it wasn't, ECH works by reading public keys from DNS, so the domain owner has claimed "you can send ECH" and it's pretty easy to know "therefore you shouldn't downgrade if you are capable, it's probably an attacker". Though unencrypted DNS renders this all a bit moot of course.
---
tl;dr, with the caveat that IANAWebSecuritySpecialist and I haven't found anything I'd call actually conclusive yet:
I believe "no". Unless you are setting up client-side CAs, at which point you can MITM everything so it hardly matters.
E.g. historically you could figure out IP <-> domain name pretty easily by simply watching DNS: cache the IP addresses for each domain as it's looked up, and do a reverse lookup when a request for that IP occurs. DNSSEC / DNS over HTTPS / etc hide that data, so it has to come from other sources (e.g. a remote lookup, bulk cached data, etc) or simply not be known at all.
You could also pull the data from the HTTPS handshake, which has Server Name Indication to support multiple domains behind a single IP address (e.g. hosted in a cloud), if that data exists (single-site static IPs may not have this). But Encrypted Client Hello hides this, so you're back to just IP addresses. (ECH is not very widespread yet AFAIK, but it's growing)
---
You can work around much of this if you have your router MITM your traffic, but that's kinda a pain to set up (as it should, it'd be very bad if someone else did it and you didn't notice), and essentially only works with "common" requests (e.g. https) which aren't using certificate pinning (a small number of mobile apps do this, outside that it's more rare AFAICT). You can just block all those of course, but it'll break some things.