These days with the prevalance of HTTPS, another option is to inspect the TLS client hello packet. To work well with load balancers etc, clients typically indicate the server name that they're trying to connect to (SNI - https://en.wikipedia.org/wiki/Server_Name_Indication). That information is not encrypted. So you have both the dst IP and hostname in the initial packet.
You probably can. But it would require a custom app that doesn't use the same cname for DNS resolution, SNI and then inside follow-up requests in the Host header. A web-browser would e.g. just use the same values for all of those, and then you either get charged or would end up at facebook.com.
It's indeed pretty simple for TLS over TCP, since the whole ClientHello is part of the first packet and relatively easy parse or seek for. With QUIC it becomes a major pain, since it's not obvious anymore for middleboxes which QUIC packet is the first in a connection, and since Crypto data can be fragmented and reordered (Chrome is doing that by purpose even inside single packets). Therefore hardware inspection would require a pretty full-featured QUIC protocol parser and understanding.
