Amos Jeffries schrieb:
Why should I use all directives for configuring a reverse proxy, if it
works with the setup explained above?
Or, am I missing something important here?
Yes. Transparent/intercept only works in the presence of NAT.
It also is not possible to perform any form of authentication, HTTPS, or
request modification without causing major problems to anyone who visits
the site.
All the old problems squid 2.5 has with virtual hosted domains, broken
client software, DNS loops, and request forwarding loops can be tracked
back to the reverse-accelerator mode using the transparent intercept
mode like you describe.
Does this also mean that using Squid as a reverse proxy with website's
DNS entry pointed at Squid machine is the only way to reliably cache web
traffic to the webserver?
I imagined I can have an accelerating/caching proxy for a webserver in
at least two different setups:
1) point webserver's DNS entry at Squid's IP; Squid will do all
caching/proxying when working in reverse (more reliable) or transparent
(less reliable) mode
2) don't change anything in DNS, but instead, make sure routing to the
webserver goes through the Squid machine, i.e.:
client -> Squid (public IP) -> webserver (public IP)
Here, we perhaps have to use transparent/intercept mode.
3) are there any other modes than 1) and 2) which could be used for
caching/accelerating traffic from a webserver?
How reliable would be to use 2), provided I use anything newer than
Squid 2.5? Your reply seem to suggest that problems with
transparent/intercept mode used for reverse proxying apply to Squid 2.5,
but it doesn't mention if newer Squid versions will work better in such
scenarios.
--
Tomasz Chmielewski
http://wpkg.org
