I'm adding this as a result of my research. I think it's potentially useful documentation. The module works as designed, but for GET requests, with the page cache on, the cache gets there before this module has a chance to have an opinion.
Detailed explanation and options for the more technical
The page cache introduces a service http_middleware.page_cache, this will handle the request before the KernelEvents::REQUEST that this module is listening for.
There seem to be two ways round this. Which you choose might depend on what you are trying to do. The page cache middleware is early. So the Request object is very much just the domain, path, parameters and so; and it's the potentially aliased path.
Option one: by-pass the cache for relevant paths. This is the page cache here, not the dynamic cache. That cache service checks the RequestPolicy in its method to check if it should handle() the request. You can add a tagged service to prevent it from handling a request → .
Option two: get in there before the page cache with your own middleware. As mentioned it's early so you've not got anything much Drupally to go on. Lots of services won't work because they depend on things loaded in the Kernel. It might help to know that service path_processor_manager will work to at least to processInbound() path at this stage.
Active
1.1
Documentation
I think I'm okay with this module acting after the page cache. We can't control page caching that happens outside of Drupal anyway, and I'd rather avoid introducing a discrepancy in behavior based on where the cached page comes from.