Assuming that you already have an origin server in place, you need to move it to a different IP address or TCP port. For example, you can (1) install Squid on a separate machine, (2) give the origin server a new IP address, and (3) give Squid the origin server's old IP address. In the interest of security, you can use non-globally routable addresses (i.e., from RFC 1918) on the link between Squid and the backend server. See Figure 15-1.
Another option is to configure Squid for HTTP interception, as described in Chapter 9. For example, you can configure the origin server's nearest router or switch to intercept HTTP requests and divert them to Squid.
If you don't have the resources to put Squid on a dedicated system, you can run it alongside the HTTP server. However, both applications can't share the same IP address and port number. You need to make the backend server bind to a different address (e.g., 127.0.0.1) or move it to another port number. It might seem easiest to change the port number, but I recommend changing the IP address instead.
Changing the port number can be problematic. For example, when the backend server generates an error message, it may expose the "wrong" port. Even worse, if the server generates an HTTP redirect, it typically appends the nonstandard port number to the Location URI:
HTTP/1.1 301 Moved Permanently Date: Mon, 29 Sep 2003 03:36:13 GMT Server: Apache/1.3.26 (Unix) Location: http://www.squid-cache.org:81/Doc/
If a client receives this response, it makes a connection to the nonstandard port (81), thus bypassing the server accelerator. If you must run Squid on the same host as your backend server, it is better to tell the backend server to listen on the loopback address (127.0.0.1). With Apache, you'd do it like this:
BindAddress 127.0.0.1 ServerName www.squid-cache.org
Once you've decided how to relocate your origin server, the next step is to configure Squid.