![[PukiWiki]](image/pukiwiki.png "[PukiWiki]")
いくつかの可能性があります。
Privoxy が動作していない。解決方法：Privoxy が正しくインストールされているか、クラッシュしていないか、確かに動作しているか、確認する。Privoxy のログを有効化してログの内容を見る。
あるいは、ブラウザに Privoxy が使っているものとは別のポートが設定されている。解決方法：Privoxy とブラウザに同じポート(listen アドレス)が設定されている事を確認する。
あるいは、転送ルールを使っている場合に、設定の問題か転送の連鎖中のホストに問題がある。解決方法：一時的に設定を変更してルールから転送先を抜く(原文：take the forwarders out of the equation)。
あるいは、干渉しブロックしているファイヤウォールが存在する。解決方法：単純なテストとしてファイヤウォールを無効化するか削除してみる。
TCP/IP ネットワークに問題がありそうです。こうした症状を ZoneAlarm が(実行していない場合であっても)引き起こすことが報告されています。解決方法は、ZoneAlarm の設定と戦うか、ZoneAlarm をアンインストールしてより良く動作する代わりを見つけることです。正しく設定されていない場合、ほかの個人用ファイヤウォール製品も同様の問題を引き起こす場合があります。
URL を追加する前に広告が表示されていたのなら、恐らくブラウザのキャッシュに保持されていてサーバへのリクエスト要求なしに、すなわち Privoxy が関わる事無しに表示されているのでしょう。ブラウザのキャッシュを消去(flush)して、もう一度試してください。
改善されない場合には、恐らく適用したルールに誤りがあります。気に入らない広告の URL 全体を http://config.privoxy.org/show-url-info 中に貼り付けて新しいルールに実際にマッチしているか見てください。広告のブロックは spam のブロックに似ています。争いに勝利する為にはたくさんの試行錯誤が必要です。対象の広告の URL をブロックする必要があるのであって、サイトの URL 自身をブロックする事とは全く違うかも知れない事を忘れてはいけません。ほとんどの広告はメインのサイト自身とは異なるサーバーで提供されています。広告上で右クリックすれば、必要な関連情報を得られるはずです。あるいは、Privoxy のログを見る事で正しい URL を見つけられます(無効化されている場合、メイン設定ファイルでログ機能を有効化する必要があります)。
下記に少し変更した現実のログの一部分を示します。URL: www.example.com (この例の為にサイト名は変更しましたが、リクエスト数は実際のものです)に対するリクエストに端を発するものです。ひとつの「ページ」を構成するものの複雑さを見てとることができるでしょう。8 つの異なるドメインが関係しており、画像、Flash、JavaScript、CSS、スクリプト、その他内容から成る、全部で 32 の異なる URL が要求されています。これらの内容のうちいくつかは明白に「良い」か「悪い」か分かりますが、全てではありません。より疑問のあるリクエストのうち多数は、名前自体が疑わしいと特定できる外部ドメインへのリクエストであり、作業がすこし簡単になります。この例では Privoxy はたくさんの項目を "crunch" (横取りしたかブロックしたことを意味します) していますが、恐らく同様にいくつかは見過ごしているでしょう。
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
32 のリクエスト中 12 がブロックされているにもかかわらず、ページは完全に「普通」(もちろんいくつかの広告なし)に動作しているように見えました。
まず最初に、実際に Privoxy の問題か確認してください。http://config.privoxy.org/toggle で Privoxy をオフに切り替えて(切り替え機能をメイン設定ファイルで有効にする必要があるかもしれません)、shift を押しながら再読み込みをクリックして問題のページを再読み込みしてみてください。あるいは、ブラウザのディスクキャッシュ、メモリキャッシュを消去(flush)してください。
もし問題が無くなったら、設定に関連した問題があることが分かります。今度は、http://config.privoxy.org/show-url-info に行き、問題のページの URL 全体を入力欄に貼り付けてください。どのアクションがその URL に適用されているか、どのアクションファイルのどのマッチがそれに対応しているかを確認してください。他に何が起こっているかを確認する為に、このサイトに関するログを見る事も助けになるかもしれません(注意：ログ機能をメイン設定ファイルで有効にする必要があるかもしれません)。複雑なサイトはたくさん有り、その内容を提示する為にたくさんの関連ページが必要です。問題のページに使われているかもしれない何か、何が必要とされているかを確認してください。これらの情報を基に、http://config.privoxy.org/show-status に行って、適切なアクションファイルを編集のために選択してください。
今や、問題を引き起こしている疑いのあるアクションを無効化する為のセクションを探してあなたのサイトに対するパターンを追加したり、全く新しいセクションを作成する事が出来ます。どんな場合でも、一番疑いの強いものだけを無効化して問題のページを再読込し、問題が残っている場合にのみよりたくさんのアクションを原因が見つかるまで無効化していくことを推奨します。再度、他のアクションを有効にするべき場合もすべきでない場合もあるでしょう。変更を行った際には、ブラウザのキャッシュを消去(flush)することを忘れずに！
別の方法として、テキストエディタの使用に問題がなければ適切なアクションファイルを編集する事でも同じことが実現できます。恐らく、そのような問題に対処するために手作業で編集する時に最も簡単な方法は、あなたのサイトを user.action の {fragile} セクションに追加することです。これはほとんどの「危険な」アクションを無効にするエイリアスですが、必要以上にたくさんのアクションを無効化しがちですし結果としてプライバシーや保護を必要以上に弱めがちです。
トラブルシューティングについてはユーザーマニュアルの付録「トラブルシューティング：アクション解体新書」でより詳細に議論されています。一般的な設定情報や例を含むアクションのチュートリアルもあります。
最終手段として、ブラウザに選択したサイトに対してプロキシをバイパスする設定があるかを確認する事ができます。現代的なブラウザはその設定が可能です。
これは Privoxy のインストールと、Internet Explorer、Windows 2000 と Windows XP にあるインターネット接続の共有が結びついて影響した思いがけない出来事(quirk)です。兆候は壊れたあるいは無効な DUN(訳註：ダイアルアップネットワーク) 設定やパスワードとして現れるかもしれません。
NT ベースの Windows システムに Privoxy を設定する歳に、期待通りにいっていないことに気付くかもしれません。システムを設定する際に、恐らく管理者権限でログインしてダイアルアップネットワーク(DUN)とインターネット接続の共有(ICS)を設定するでしょう。また恐らく、このダイアルアップネットワーク接続をシステム上の他のアカウントにも有効にするでしょう。例えば、両親がシステムを設定し子供達に適した設定のアカウントを作る場合などです。
この環境下で Privoxy を設定する時には、Privoxy を使用したい特定のダイアルネットワーク接続設定に対して Internet Explorer のプロキシ設定を変更する必要があるでしょう。こうした場合、インターネット接続の共有がなされたダイアルアップネットワーク接続の設定はユーザー個別になります。この例では、接続の設定を行ったアカウントでダイアルアップネットワーク接続を変更した場合には(他のアカウントでも)何も違いはありません。しかし、別のユーザーから変更を行った場合はダイアルアップネットワーク接続の設定が「自分だけ」に有効であることに気付くでしょう。それぞれのユーザーに対してパスワードを保存しなければならない事にも気付くでしょう。
これは IE の設定がユーザー個別であるためです。ダイアルアップネットワーク接続と IE の LAN 接続の設定はユーザー毎にそれぞれ保存されます。そのため共通の設定ではなく個別の設定が強制されます。このため、再起動後最初にダイアルアップネットワーク接続を使用する時には期待通りに動作せずパスワードの入力画面が表示されるかもしれません。再度パスワードを入力、保存する事で万事うまく行くはずです。
[本項について Ray Griffith に感謝します。]
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".
