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".
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, + 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.
+The upgrade process to Mac OS X Mavericks (10.9) from an earlier version of OS X deletes all user accounts + that are either not part of OS X itself or are not interactive user accounts (ones you log in with). Since, for + the sake of security, Privoxy runs as a non-privileged user that is created by + its installer (_privoxy), it can no longer start up once that account gets deleted. The solution is to perform a + complete uninstall using the supplied uninstall.command script (either back up + your configuration files or select to not have the uninstaller remove them when it prompts you) and then + reinstall Privoxy using the installer package and merge in your + configuration.
+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 may be the result of an overly aggressive filter. The filters that are enabled in the default + configuration aren't expected to cause problems like this. If you enabled the "demoronizer" filter, please try temporarily disabling it.
+If that doesn't help, temporarily disable all filters to see if another filter could be the culprit. If the + problem disappears, enable the filters one by one, until the problem reappears and the offending filter is + found.
+Once the problem-causing filter is known, it can be fixed or disabled.
+Upgrading Privoxy, or going to the most recent default.action file available from git might be worth a try, too.
+This may also be caused by an (overly aggressive filter in conjunction + with a web server that is misreporting the content type. By default binary files are exempted from Privoxy's filtering (unless the web server by mistake says the file is something else).
+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.
+You can also prevent the problem by enabling https-inspection in which case Privoxy's error messages are delivered encrypted.
+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".
+Privoxy marks sockets as tainted when it can't use them to serve additional + requests. This does not necessarily mean that something went wrong and information about tainted sockets is only + logged if connection debugging is enabled (debug 2).
+For example server sockets that were used for CONNECT requests (which are used to tunnel https:// requests) + are considered tainted once the client closed its connection to Privoxy. + Technically Privoxy could keep the connection to the server open, but the server + would not accept requests that do not belong to the previous TLS/SSL session (and the client may even have + terminated the session).
+Server sockets are also marked tainted when a client requests a resource, but closes the connection before + Privoxy has completely received (and forwarded) the resource to the client. In + this case the server would (probably) accept additional requests, but Privoxy + could not get the response without completely reading the leftovers from the previous response.
+These are just two examples, there are currently a bit more than 25 scenarios in which a socket is considered + tainted.
+While sockets can also be marked tainted as a result of a technical problem that may be worth fixing, the + problem will be explicitly logged as error.
+This can happen if your custom filters require more memory than Privoxy is + allowed to use. Usually the problem is that the operating system enforces a stack size limit that isn't + sufficient.
+Unless the problem occurs with the filters available in the default configuration, this is not considered a + Privoxy bug.
+To prevent the crashes you can rewrite your filter to use less resources, increase the relevant memory limit + or recompile pcre to use less stack space. For details please see the pcrestack man page and the documentation of + your operating system.
+Your userid probably isn't allowed to edit the file. On Windows you can use the windows equivalent of + sudo:
+
+ runas /user:administrator "notepad \privoxy\config.txt"+ |
+
or fix the file permissions:
+
+ C:\Privoxy>icacls config.txt + config.txt BUILTIN\Administrators:(I)(F) + NT AUTHORITY\SYSTEM:(I)(F) + BUILTIN\Users:(I)(RX) + NT AUTHORITY\Authenticated Users:(I)(M) + + Successfully processed 1 files; Failed processing 0 files + + C:\Privoxy>icacls config.txt /grant Lee:F + processed file: config.txt + Successfully processed 1 files; Failed processing 0 files + + C:\Privoxy>icacls config.txt + config.txt I3668\Lee:(F) + BUILTIN\Administrators:(I)(F) + NT AUTHORITY\SYSTEM:(I)(F) + BUILTIN\Users:(I)(RX) + NT AUTHORITY\Authenticated Users:(I)(M) + + Successfully processed 1 files; Failed processing 0 files + + C:\Privoxy>+ |
+
or try to point-n-click your way through adjusting the file permissions in windows explorer.
+