das Problem existiert nur mehr in dem Link (2001!)Transparent proxying (more commonly known as TCP hijacking) is like Network Address Translation (NAT) in some respects: It is to be avoided at all costs, and only used if there absolutely, positively, no other way.
Why? Because transparent proxying does not work very well with certain web-browsers. With most browsers you're fine, but if even a quarter of your users are using badly behaved browsers, you can expect your help desk costs to exceed any benefits you might gain from transparent proxying. Unfortunately, these browsers are in wide use.
These browsers behave differently if they are aware of a proxy -- all other browsers follow the standard, and the only change they make with a proxy is to direct the requests to a different machine and port. Badly behaved browsers leave some of the HTTP headers out of their requests, and only add them when they know there's a proxy. Without those headers, user commands like "reload" don't work if there's a proxy between the user and the source.
Einen Proxy (vorallem Squid) kann ich einrichten so das, dass nicht passiertTransparent proxying also introduces a layer of complexity, which can complicate otherwise simple transactions. For instance, a web-based application that requires an active server cannot test for the server by making a connection -- it will connect to the proxy, instead.
Du kannst mit gutem Gewissen einen transparenten Squid einrichten.
markus
egal ob es mittlerweile "problemlos" geht oder nicht, man kann ja auch fragen, warum transparent - man kann systemweite Vorgaben für den Proxy per Environment und Default Browserkonfiguration setzen. (wget, rsync & co könnens alle per ENV ).