There are several possibilities:
Privoxy is not running. Solution: verify that Privoxy is installed correctly, has not crashed, and is indeed running. Turn on Privoxy's logging, and look at the logs to see what they say.
Or your browser is configured for a different port than what Privoxy is using. Solution: verify that Privoxy and your browser are set to the same port (listen-address).
Or if using a forwarding rule, you have a configuration problem or a problem with a host in the forwarding chain. Solution: temporarily alter your configuration and take the forwarders out of the equation.
Or you have a firewall that is interfering and blocking you. Solution: try disabling or removing the firewall as a simple test.
More than likely this is a problem with your TCP/IP networking. ZoneAlarm has been reported to cause this symptom -- even if not running! The solution is to either fight the ZA configuration, or uninstall ZoneAlarm, and then find something better behaved in its place. Other personal firewall type products may cause similar type problems if not configured correctly.
If the ad had been displayed before you added its URL, it will probably be held in the browser's cache for some time, so it will be displayed without the need for any request to the server, and Privoxy will not be involved. Flush the browser's caches, and then try again.
If this doesn't help, you probably have an error in the rule you applied. Try pasting the full URL of the offending ad into http://config.privoxy.org/show-url-info and see if it really matches your new rule. Blocking ads is like blocking spam: a lot of tinkering is required to stay ahead of the game. And remember you need to block the URL of the ad in question, which may be entirely different from the site URL itself. Most ads are hosted on different servers than the main site itself. If you right-click on the ad, you should be able to get all the relevant information you need. Alternately, you can find the correct URL by looking at Privoxy's logs (you may need to enable logging in the main config file if its disabled).
Below is a slightly modified real-life log snippet that originates with one requested URL: www.example.com (name of site was changed for this example, the number of requests is real). You can see in this the complexity of what goes into making up this one "page". There are eight different domains involved here, with thirty two separate URLs requested in all, making up all manner of images, Shockwave Flash, JavaScript, CSS stylesheets, scripts, and other related content. Some of this content is obviously "good" or "bad", but not all. Many of the more questionable looking requests, are going to outside domains that seem to be identifying themselves with suspicious looking names, making our job a little easier. Privoxy has "crunched" (meaning caught and BLOCKED) quite a few items in this example, but perhaps missed a few as well.
Request: www.example.com/ Request: www.example.com/favicon.ico Request: img.example.com/main.css Request: img.example.com/sr.js Request: example.betamarker.com/example.html Request: www.lik-sang.com/Banners/bestsellers/skyscraper.php?likref=BSellers Request: img.example.com/pb.png Request: www.google-analytics.com/urchin.js crunch! (Blocked) Request: www.advertising-department.com/ats/switch.ps.php?26856 crunch! (Blocked) Request: img.example.com/p.gif Request: www.popuptraffic.com/assign.php?l=example&mode=behind crunch! (Blocked) Request: www.popuptraffic.com/scripts/popup.php?hid=5c3cf&tmpl=PBa.tmpl crunch! (Blocked) Request: www.popuptraffic.com/assign.php?l=example crunch! (Blocked) Request: www.lik-sang.com/Banners/best_sellers/best_sellers.css Request: www.adtrak.net/adx.js crunch! (Blocked) Request: img.example.com/hbg.gif Request: img.example.com/example.jpg Request: img.example.com/mt.png Request: img.example.com/mm.png Request: img.example.com/mb.png Request: www.popuptraffic.com/scripts/popup.php?hid=a71b91fa5&tmpl=Ua.tmp crunch! (Blocked) Request: www.example.com/tracker.js Request: www.lik-sang.com/Banners/best_sellers/lsi_head.gif Request: www.adtrak.net/adjs.php?n=020548130&what=zone:61 crunch! (Blocked) Request: www.adtrak.net/adjs.php?n=463594413&what=zone:58&source=Ua crunch! (Blocked) Request: www.lik-sang.com/Banners/best_sellers/bottomani.swf Request: mmm.elitemediagroup.net/install.php?allowpop=no&popupmincook=0&allowsp2=1 crunch! (Blocked) Request: www.example.com/tracker.js?screen=1400x1050&win=962x693 Request: www.adtrak.net/adlog.php?bannerid=1309&clientid=439&zoneid=61 crunch! (Blocked) Request: 66.70.21.80/scripts/click.php?hid=5c3cf599a9efd0320d26&si Request: 66.70.21.80/img/pixel.gif Request: www.adtrak.net/adlog.php?bannerid=1309&clientid=439&zoneid=58&source=Ua&block=86400 crunch! (Blocked) Request: 66.70.21.80/scripts/click.php?hid=a71b9f6504b0c5681fa5&si=Ua |
Despite 12 out of 32 requests being blocked, the page looked, and seemed to behave perfectly "normal" (minus some ads, of course).
First verify that it is indeed a Privoxy problem, by toggling off Privoxy through http://config.privoxy.org/toggle (the toggle feature may need to be enabled in the main config), and then shift-reloading the problem page (i.e. holding down the shift key while clicking reload. Alternatively, flush your browser's disk and memory caches).
If the problem went away, we know we have a configuration related problem. Now go to http://config.privoxy.org/show-url-info and paste the full URL of the page in question into the prompt. See which actions are being applied to the URL, and which matches in which actions files are responsible for that. It might be helpful also to look at your logs for this site too, to see what else might be happening (note: logging may need to be enabled in the main config file). Many sites are complex and require a number of related pages to help present their content. Look at what else might be used by the page in question, and what of that might be required. Now, armed with this information, go to http://config.privoxy.org/show-status and select the appropriate actions files for editing.
You can now either look for a section which disables the actions that you suspect to cause the problem and add a pattern for your site there, or make up a completely new section for your site. In any case, the recommended way is to disable only the prime suspect, reload the problem page, and only if the problem persists, disable more and more actions until you have identified the culprit. You may or may not want to turn the other actions on again. Remember to flush your browser's caches in between any such changes!
Alternately, if you are comfortable with a text editor, you can accomplish the same thing by editing the appropriate actions file. Probably the easiest way to deal with such problems when editing by hand is to add your site to a { fragile } section in user.action, which is an alias that turns off most "dangerous" actions, but is also likely to turn off more actions then needed, and thus lower your privacy and protection more than necessary,
Troubleshooting actions is discussed in more detail in the User Manual appendix, Troubleshooting: the Anatomy of an Action. There is also an actions tutorial with general configuration information and examples.
As a last resort, you can always see if your browser has a setting that will bypass the proxy setting for selective sites. Modern browsers can do this.
This is a quirk that affects the installation of Privoxy, in conjunction with Internet Explorer and Internet Connection Sharing on Windows 2000 and Windows XP. The symptoms may appear to be corrupted or invalid DUN settings, or passwords.
When setting up an NT based Windows system with Privoxy you may find that things do not seem to be doing what you expect. When you set your system up you will probably have set up Internet Connection Sharing (ICS) with Dial up Networking (DUN) when logged in with administrator privileges. You will probably have made this DUN connection available to other accounts that you may have set-up on your system. E.g. Mum or Dad sets up the system and makes accounts suitably configured for the kids.
When setting up Privoxy in this environment you will have to alter the proxy set-up of Internet Explorer (IE) for the specific DUN connection on which you wish to use Privoxy. When you do this the ICS DUN set-up becomes user specific. In this instance you will see no difference if you change the DUN connection under the account used to set-up the connection. However when you do this from another user you will notice that the DUN connection changes to make available to "Me only". You will also find that you have to store the password under each different user!
The reason for this is that each user's set-up for IE is user specific. Each set-up DUN connection and each LAN connection in IE store the settings for each user individually. As such this enforces individual configurations rather than common ones. Hence the first time you use a DUN connection after re-booting your system it may not perform as you expect, and prompt you for the password. Just set and save the password again and all should be OK.
[Thanks to Ray Griffith for this submission.]
Privoxy cannot act as a proxy for FTP traffic, so do not configure your browser to use Privoxy as an FTP proxy. The same is true for any protocol other than HTTP or HTTPS (SSL).
Most browsers understand FTP as well as HTTP. If you connect to a site, with a URL like ftp://ftp.example.com, your browser is making an FTP connection, and not a HTTP connection. So while your browser may speak FTP, Privoxy does not, and cannot proxy such traffic.
To complicate matters, some systems may have a generic "proxy" setting, which will enable various protocols, including both HTTP and FTP proxying! So it is possible to accidentally enable FTP proxying in these cases. And of course, if this happens,