Hi Peter, >From what I understand, if you use WCCP, you do not exactly re-write the packet destination address but you use your router to give your packet a 'coat' or encapsulation without modifying the packet inside the encapsulation. The machine to which the encapsulated packet is directed removes the 'coat' and treats the packet as would any proxy specified in the browser. The information about the destination webserver is not lost in the process. Ralph -----Original Message----- From: Peter Djalaliev [mailto:pdjalaliev@xxxxxxxxxxxxx] Sent: Tuesday, July 08, 2008 1:46 AM To: squid-users@xxxxxxxxxxxxxxx Subject: how does squid work as a transparent proxy? Hello, I am new to Squid and I'd like to ask a question about its internal workings when operating as a transparent proxy. I saw that one configure the host kernel with an iptables rule in the nat table with the REDIRECT target to match packets destined to some port (e.g 80) and redirect them to some other port on the local host (e.g 3128). From what I understand, when iptables matches a packet against this rule, it overwrites the packet's destination IP address and TCP port with, respectively, the local IP address and 3128. How does Squid (e.g in the case of an HTTP request) know the IP address of the original web server that the packet was destined to? For example, if the GET-ed object doesn't exist in cache, how does Squid know where to connect() to and request the object? I tried looking at the source code and it looks like in some cases Squid might be parsing the domain name from the GET request and using a DNS lookup on this domain name to determine the IP address. Is this always the case? If yes, does Squid do something similar in the case of other supported protocols - SSL, gopher? Regards, Peter Djalaliev
