However there are also significant disadvantages for this strategy, as outlined by Mark Elsen:

    * Intercepting HTTP breaks TCP/IP standards because user agents think they are talking directly to the origin server.
    * It causes path-MTU (PMTUD) to fail, possibly making some remote sites inaccessible. This is not usually a problem if your client machines are connected via Ethernet or DSL PPPoATM where the MTU of all links between the cache and client is 1500 or more. If your clients are connecting via DSL PPPoE then this is likely to be a problem as PPPoE links often have a reduced MTU (1472 is very common).
    * On older IE versions before version 6, the ctrl-reload function did not work as expected.
    * Proxy authentication does not work, and IP based authentication conceptually fails because the users are all seen to come from the Interception Cache's own IP address.
    * You can't use IDENT lookups (which are inherently very insecure anyway)
    * Interception Caching only supports the HTTP protocol, not gopher, SSL or FTP. You cannot setup a redirection-rule to the proxy server for other protocols other than HTTP since it will not know how to deal with it.
    * Intercepting Caches are incompatible with IP filtering designed to prevent address spoofing.
    * Clients are still expected to have full Internet DNS resolving capabilities; in certain intranet/firewalling setups, this is not always wanted.
    * Related to above: suppose the users browser connects to a site which is down. However, due to the transparent proxying, it gets a connected state to the interceptor. The end user may get wrong error messages or a hung browser, for seemingly unknown reasons to them. 

If you feel that the advantages outweigh the disadvantages in your network, you may choose to continue reading and look at implementing Interception Caching.