…or use higher-level packet analysis to filter DoH.

That kind of DPI is computationally expensive to the point China doesn't even do it much.

OMG, they very much do. It is not on 100% of the traffic but at any given time a more then smaller % is subject to DPI.

Not anymore and mainland Chinese manufacturers sell them on in large numbers to autocratic governments.

Such devices have a pretty simple architecture: the highly performant data plane where DPI is implemented in the hardware (using either ASIC's or FPGA's – don't have enough information), and the control plane. The control plane comes with a SDK of sorts that DPI appliance users can use to tailor the appliance to their environment and that is used to «refine» the data plane behaviour, i.e. sending down / updating DPI pattern matching / processing rules.

With HTTP/3 there isn't much higher level packet analysis to do between anything useful in the headers being encrypted and the session being reused. All you see is there is a 443 UDP session to a Google server and encrypted packets keep getting sent back and forth... which looks exactly like any other HTTP/3 session to a Google server.

I think the weak points are wholly untechnical e.g. Google would often give in to protect the $$$ they make in a region.

Packet size (i forget if http/3 does padding) and packet rates are still available, dns looks a lot different than most http content.

In terms of packet size, DNS (DoH) doesn’t really look any different to an XHR request.

Request maybe, DoH responses are probably way shorter than anything else though.

Then they will block Google Search and blame it on Google ?