So far, we have only covered the Config options that directly relate to accelerator mode.
Accelerating a slow web server is only useful if the cache can keep copies of returned pages (so that it can avoid contacting the back-end server.) Since you know about the backend server, you can specify refresh patterns that suit the machine exactly. Refresh patterns aren't covered here (they are covered in-depth in Chapter 11), but it's worth looking at how your site changes, and tuning your refresh patterns to match.
If, on the other hand, you are using simply using accelerator mode to replace a combination cache (or to act as a secure front-end for another server), you can disable caching of that site altogether: otherwise you simply end up duplicating data (once on the origin site, once for the cached copy) with no benefit.
Presumably you will want people from outside your network to be able to access the web server that Squid is accelerating. If you have based your access lists on the examples in this book, you will find that machines on the outside cannot access the site being accelerated. The accelerated request is treated exactly like a normal http request, so people accesing the site from the outside world will be rejected since your acl rules deny access from IPs that are not on your network. By using the dst acl type, you can add specific exclusions to your access lists to allow requests to the accelerated host.
In the following example, we have changed the config so that the first rule matches (and allows) any request to the machine at IP 10.0.0.5, the accelerated machine. If we did not have the port acl in the below rules, someone could request a URL with a different port number with a request that explicitly specifies a non-standard port. If we were to leave out this rule, it could let a system cracker poke around the system with requests for things like http://server.mydomain.example:25.