| Next |
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).
Privoxy problem, - by disabling Privoxy filtering and blocking. - Go to 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 http://p.p/ and click on +>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 "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.
"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. +If still a problem, go to 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 + 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 PHP, + which results in empty pages being sent if the client explicitly requests + an uncompressed page, like Privoxy features disabled for specific - sites. Most disabled 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 + "shop" and "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 "fragile", and won't necessarily - use a "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 "+" or "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 + user-manual appendix.
Javascript + in this case, with the unsolicited-popups + filter. Privoxy cannot tell very well + "good" code snippets from "bad" code snippets.Alternately, if you are comfortable with a text editor, you can accomplish - the same thing by editing the appropriate 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 "actions" file.
"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.
Feedback is encouraged, whether good, bad or ugly. Please see the contact - page in the 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 +user-manual for - details.
prevent-compression.As of Privoxy 3.0.9, zlib support is enabled in the default builds.
Time for you to go!
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".