Either Privoxy is not running, or your - browser is configured for a different port than what - Privoxy is using.
The old Privoxy (and also - Junkbuster) used port 8000 by - default. This has been changed to port 8118 now, due to a conflict - with NAS (Network Audio Service), which uses port 8000. If you haven't, - you need to change your browser to the new port number, or alternately - change Privoxy's "listen-address" - setting in the config file used to start - Privoxy.
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 in the picture. The best thing to do is try flushing 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 any actions match your new rule.
First verify that it is indeed a Privoxy problem, - by disabling Privoxy filtering and blocking. - Go to http://p.p/ and click on - "Toggle Privoxy On or Off", then disable it. Now try that - page again. It's probably a good idea to flush the browser cache as well.
If still a problem, go to "Show which actions apply to a URL and - why" from http://p.p/ and paste - the full URL of the page in question into the prompt. See which actions are - being applied to the URL. Now, armed with this information, go to "Edit - the actions list". Here you should see various sections that have - various Privoxy features disabled for specific - sites. Most disabled "actions" will have a "-" (minus - sign) in front of them. Some aliases are used just to disable other actions, - e.g. "shop" and "fragile", and won't necessarily - use a "+" or "-" sign. Add your problem page - URL to one of these sections that looks like it is disabling the feature that - is causing the problem. Rember to flush your browser's caches when making - such changes! As a last resort, try "fragile" which - disables most actions. Now re-try the page. There might be some trial and - error involved. This is discussed in a little more detail in the user-manual appendix.
Alternately, if you are comfortable with a text editor, you can accomplish - the same thing by editing the appropriate "actions" file.
Feedback is encouraged, whether good, bad or ugly. Please see the contact - page in the user-manual for - details.
Time for you to go!
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 effects 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, Privoxy will indeed cause problems since it does + not know FTP. Newer version will give a sane error message if a FTP + connection is attempted. Just disable the FTP setting and all will be + well again.
+ +Will Privoxy ever proxy FTP + traffic? Unlikely. There just is not much reason, and the work to make + this happen is more than it may seem.
+Microsoft Internet Explorer (in versions like 5.1) respects + system-wide network settings. In order to change the HTTP proxy, open + System Preferences, and click on the Network icon. In the settings pane + that comes up, click on the Proxies tab. Ensure the "Web Proxy (HTTP)" + checkbox is checked and enter 127.0.0.1 in the + entry field. Enter 8118 in the Port field. The + next time you start IE, it should reflect these values.
+Note: This ONLY applies to privoxy 3.0.6 and earlier.
+ +Just dragging the Privoxy folder to + the trash is not enough to delete it. Privoxy supplies an uninstall.command file that takes care of these + details. Open the trash, drag the uninstall.command file out of the trash and + double-click on it. You will be prompted for confirmation and the + administration password.
+ +The trash may still appear full after this command; emptying the + trash from the desktop should make it appear empty again.
+We believe this is due to an IPv6-related bug in Mac OS X, but don't + fully understand the issue yet. In any case, changing the proxy setting + to 127.0.0.1 instead of localhost works around the problem.
+Chances are that the site suffers from a bug in PHP, which results in empty pages being sent + if the client explicitly requests an uncompressed page, like + Privoxy does. This bug has been fixed + in PHP 4.2.3.
+ +To find out if this is in fact the source of the problem, try adding + the site to a -prevent-compression section in + user.action:
+ +
+
+ # Make exceptions for ill-behaved sites:
+ #
+ {-prevent-compression}
+ .example.com
+
+ |
+
If that works, you may also want to report the problem to the site's + webmasters, telling them to use zlib.output_compression instead of + ob_gzhandler in their PHP applications (workaround) or upgrade to PHP + 4.2.3 or later (fix).
+Privoxy tries to get the hostname + of the system its running on from the IP address of the system + interface it is bound to (from the config + file listen-address setting). + If the system cannot supply this information, Privoxy logs this condition.
+ +Typically, this would be considered a minor system configuration + error. It is not a fatal error to Privoxy however, but may result in a much slower + response from Privoxy on some + platforms due to DNS timeouts.
+ +This can be caused by a problem with the local hosts file. If this file has been changed from the + original, try reverting it to see if that helps. Make sure whatever + name(s) are used for the local system, that they resolve both ways.
+ +You should also be able to work around the problem with the hostname + option.
+Port 8118 is Privoxy's default TCP + "listening" port. Typically this message + would mean that there is already one instance of Privoxy running, and your system is actually + trying to start a second Privoxy on + the same port, which will not work. (You can have multiple instances + but they must be assigned different ports.) How and why this might + happen varies from platform to platform, but you need to check your + installation and start-up procedures.
+This is caused by the "demoronizer" + filter. You should either upgrade Privoxy, or at least upgrade to the most recent + default.action file available from SourceForge. Or you can simply disable the demoronizer + filter.
+This may also be caused by the "demoronizer" filter, in conjunction with a web server + that is misreporting the content type. Binary files are exempted from + Privoxy's filtering (unless the web + server by mistake says the file is something else). Either upgrade + Privoxy, or go to the most recent + default.action file available from SourceForge.
+The original demoronizer was a Perl script that cleaned up HTML + pages which were created with certain Microsoft products. MS has used + proprietary extensions to standardized font encodings (ISO 8859-1), + which has caused problems for pages that are viewed with non-Microsoft + products (and are expecting to see a standard set of fonts). The + demoronizer corrected these errors so the pages displayed correctly. + Privoxy borrowed from this script, + introducing a filter based on the original demoronizer, which in turn + could correct these errors on the fly.
+ +But this is only needed in some situations, and will cause serious + problems in some other situations.
+ +If you are using Microsoft products, you do not need it. If you need + to view pages with UTF-8 characters (such as Cyrillic or Chinese), then + it will cause corruption of the fonts, and thus should not be on.
+ +On the other hand, if you use non-Microsoft products, and you + occasionally notice weird characters on pages, you might want to try + it.
+Privoxy is attempting to disable + malicious Javascript in this case, with the unsolicited-popups filter. Privoxy cannot tell very well "good" code snippets from "bad" code snippets.
+ +If you see this in HTML source, and the page displays without + problems, then this is good, and likely some pop-up window was + disabled. If you see this where it is causing a problem, such as a + downloaded program source code file, then you should set an exception + for this site or page such that the integrity of the page stays in tact + by disabling all filtering.
+There are potentially several factors here. First of all, the DNS + resolution is done by the underlying operating system -- not + Privoxy itself. Privoxy merely initiates the process and hands it + off, and then later reports whatever the outcome was and tries to give + a coherent message if there seems to be a problem. In some cases, this + might otherwise be mitigated by the browser itself which might try some + work-arounds and alternate approaches (e.g adding "www." to the URL).
+ +In other cases, if Privoxy is being + chained with another proxy, this could complicate the issue, and cause + undue delays and timeouts. In the case of a "socks4a" proxy, the socks server handles all the DNS. + Privoxy would just be the "messenger" which is reporting whatever problem occurred + downstream, and not the root cause of the error.
+ +In any case, versions newer than 3.0.3 include various improvements + to help Privoxy better handle these + cases.
+This is probably a manifestation of the "100% + cpu" problem that occurs on pages containing many (thousands + upon thousands) of blank lines. The blank lines are in the raw HTML + source of the page, and the browser just ignores them. But the pattern + matching in Privoxy's page filtering + mechanism is trying to match against absurdly long strings and this + becomes very CPU-intensive, taking a long, long time to complete.
+ +Until a better solution comes along, disable filtering on these + pages, particularly the js-annoyances and + unsolicited-popups filters. If you run into + this problem with a recent Privoxy + version, please send a problem report.
+This should not happen, and for the overwhelming number of users + world-wide, it does not happen. I would suspect some inadvertent + interaction of software components such as anti-virus software, spyware + protectors, personal firewalls or similar components. Try disabling (or + uninstalling) these one at a time and see if that helps. Either way, if + you are using a recent Privoxy + version, please report the problem.
+It's probably due to compression. It is a common practice for web + servers to send their content "compressed" + in order to speed things up, and then let the browser "uncompress" them. When compiled with zlib support + Privoxy can decompress content before + filtering, otherwise you may want to enable prevent-compression.
+ +As of Privoxy 3.0.9, zlib support + is enabled in the default builds.
+Probably the browser is requesting ads through HTTPS and + Privoxy is blocking the requests. + Privoxy's error messages are delivered unencrypted and while it's + obvious for the browser that the HTTPS request is already blocked by + the proxy, some warn about unauthenticated content anyway.
+ +To work around the problem you can redirect those requests to an + invalid local address instead of blocking them. While the redirects + aren't encrypted either, many browsers don't care. They simply follow + the redirect, fail to reach a server and display an error message + instead of the ad.
+ +To do that, enable logging to figure out which requests get blocked + by Privoxy and add the hosts (no path + patterns) to a section like this:
+ +
+
+{+redirect{http://127.0.0.1:0/} -block -limit-connect}
+.ivwbox.de:443/
+
+ |
+
Additionally you have to configure your browser to contact + "127.0.0.1:0" directly (instead of through + Privoxy).
+ +To add a proxy exception in Mozilla + Firefox open the "Preferences", click + the "Settings" button located on the + "Network" tab in the "Advanced" section, and add "127.0.0.1:0" in the "No Proxy + for:" field.
+Please report the problem to the creator of your selinux + policies.
+ +The problem is that some selinux policy writers aren't familiar with + the application they are trying to "secure" + and thus create policies that make no sense.
+ +In Privoxy's case the problem + usually is that the policy only allows outgoing connections for certain + destination ports (e.g. 80 and 443). While this may cover the standard + ports, websites occasionally use other ports as well. This isn't a + security problem and therefore Privoxy's default configuration doesn't block + these requests.
+ +If you really want to block these ports (and don't be able to load + websites that don't use standard ports), you should configure Privoxy + to block these ports as well, so it doesn't trigger the selinux + warnings.
+Probably you unintentionally compiled Privoxy without threading support in which case + requests have to be serialized and only one can be served at the same + time.
+ +Check your "USE" flags and make sure they + include "threads". If they don't, add the + flag and rebuild Privoxy.
+ +If you compiled Privoxy with + threading support (on POSIX-based systems), the "Conditional #defines" section on http://config.privoxy.org/show-status will list "FEATURE_PTHREAD" as "enabled".
+