The actions files are used to define what actions Privoxy takes for which URLs >
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".