Polipo seems to perform best when it is not tampered with and while it uses the default settings.

## Cache
# If polipo is not used by more than one person.
cacheIsShared = false

## Network
# Do not perform IPv6 queries. A minor speed-up.
dnsQueryIPv6 = no

## Webserver
# Disables all of polipo's internal webserver features
# which is a good idea if they are not used or needed.
disableConfiguration = true
disableLocalInterface = true
localDocumentRoot = ""
disableIndexing = true

## Privacy
# Disabling sending hostname or IP to upstream proxies.
disableVia = true
# Censors headers, the following do not seem to break anything.
censoredHeaders = from,accept-language,x-pad,link
censorReferer = maybe

## Blocking
# It will never resolve to anything.
forbiddenUrl = about:blank

• Any other additional options seem to make polipo slower (including setting a chunk size, etc…).
• Do not enable PMM (Poor-Man's Multiplexing), it will break websites.
• relaxTransparency, if set to true will break websites.

You can retrieve the current list of spam domains from the spam domains page and copy the domains.txt file to /etc/polipo/forbidden and let polipo filter out most ads.

Compared to dansguardian, squidGuard, privoxy and tinyproxy, it appears that polipo has the most efficient filtering system:

• dansguardian - slow, bulky, weighted system, a general mess that you will have to tweak all the time.
• squidGuard - pretty good, you have to rehash the lists, slower than polipo in any case.
• privoxy - perceivably slow filtering compared to polipo.
• tinyproxy - will crash the system if the /etc/filter URL list is sufficiently long.

This hack will suppress any output on HTTP 403 Forbidden and is useful in combination with a forbidden file that allows you to specify which domains to block such that an empty document is returned instead of a ghastly error message:

--- http.c.orig	2014-03-05 15:23:19.000000000 +0000
+++ http.c	2014-03-05 15:26:34.118668644 +0000
@@ -855,7 +855,7 @@
     else
         htmlMessage[MIN(i, 99)] = '\0';
 
-    if(code != 304) {
+    if(code != 304 && code != 403) {
         body = get_chunk();
         if(!body) {
             do_log(L_ERROR, "Couldn't allocate body buffer.\n");

The reasoning behind polipo's forbidden file is severely flawed. The author claims that the forbidden file "specifies the set of URLs that should never be fetched". However, polipo internally manages the forbidden file as a list of URLs that will return HTTP 403 to the client which is different from what the author claims. The result is that failed outcomes from an authentication procedure (ie: through HTTP) will return the same error code as any other domain from the forbidden file. This is wrong. Do not use this patch if you authenticate to services that return HTTP 403 on failure or you will get a blank document.