This issue only happens when the optimize_broadband_speed_check is enabled and requests are explicitly sent to the CacheFlow.
The first time a client requests a legitimate speed test the CacheFlow will cache the result, if the client requests the same object it will then be served from cache and the access logs will show a TCP_HIT. On the next request for that object if the hostname is changed from speedtest.com (the real host) to foo.com and the URL path remains unchanged the CacheFlow will return the cached object and show a TCP_HIT.
The reasoning behind this is the way the optimize_broadband_speed_check policy function works. To identify speedtest sites it looks at the URL path and not the host. When requests are explicitly sent to the CacheFlow there is no DNS lookup on the client and therefore the CacheFlow doesn't do any upstream verification, unless the object is stale, and serves the content directly from cache.
Under normal circumstances the CacheFlow should be deployed in a transparent manner. When in transparent mode the client will perform its own DNS lookup and if the destination IP address provided by the client doesn't match what the CacheFlow has it will go upstream to verify the object. Since the object doesn't actually exist on the host the OCS will return an HTTP error which will be passed down to the client.