あなたのIPアドレスからアクセスできるように http_access で適切な設定がなされているか確認してください。 「アクセスコントロール」について参照してください。
もしSquidをアクセラレータモードで実行しているなら、普通のHTTPアクセスを受け入れ実際のWebサーバに転送するようになっており、この場合にはプロキシとしては機能しないでしょう。 もしプロキシとしての要求も受け入れたいなら、そのための機能を有効にしなくてはなりません。
まだ原因が判らないなら、ACLの設定をミスしていると思われるので、１つ１つ ACL を squid.conf に設定しながら cache.log
をチェックしてしてください。
local_domain ディレクティブは、ローカルのオブジェクトがキャッシュされるのを防ぎません。 これはローカルオブジェクトをとって来る際に兄弟キャッシュの使用を防止します。
もし、オブジェクトのキャッシュを防止したいなら、cache_stoplist または http_stop
を使ってください。（バージョンによります）
Connection Refusedになります。兄弟キャッシュをアクセスする際、HTTPのポート番号を間違っていてもICPのポート番号が正しく設定されていれば、ICPリクエストは成功（オブジェクトが兄弟キャッシュに存在する事が判る）します。 しかし、実際のオブジェクトを兄弟キャッシュから入手しようとするとHTTPポートが間違っている為に失敗します。 兄弟キャッシュでHTTPの待ち受けポート番号を変えたなら他の兄弟キャッシュで squid.conf の設定を変更してください。
もし、"Too many open files" といったエラーメッセージが出たなら、多分あなたのシステムのファイルディスクリプタを使い果たしました。 これはファイルディスクリプタの限界の低いオペレーティングシステムを使っている場合に発生します。
この限界は、OSのカーネル構築の際に設定するか、場合によってはツールで設定できるでしょう。
Henrik の How to get many
filedescriptors on Linux 2.2.X ページまたはMichael O'Reilly のfilehandle
patch を参考にしてください。
もし、あなたのカーネルが2.2.x以上なら、以下のファイルハンドラとiノードの最大値を調べ、これを簡単に書き換える方法があります。
もしファイルハンドラ（ファイルディスクリプタ）を増やすなら、
カーネルが2.0.35 から 2.1.xの間なら、以下の内容を読み込んで特別なファイルに書き込むことで、それを増やすことができます。
一方、ファイルディスクリプタを増やしたなら、squid の configure において、新しい値にマッチした内容にヘッダーファイル（usr/include/linux/limits.h）のOPEN_MAX を増やして構築し直さないと、設定した内容が反映されません。
/etc/system の中のプロセス当たりのファイルディスクリプタの設定を変更してください。
上記の設定を行ったなら、新しい値が反映されるようトップディレクトリで configure を再度行ってください。 configureが新しい値を見つけられない場合には、include/autoconf.h を直接編集し、
もしあなたが古いSquid(1.1.x)を使っていて1024以上のファイルディスクリプタが必要なら src/Makefile の
Jens-S. Voeckler はデフォルトの soft limit (rlim_fd_cur) を 256以上にすべきではないと勧めます。 256以上にすることで、Sunワークショップコンパイラーに必要なライセンスマネージャなどのプログラムを破壊します。
１. どうやってファイルディスクリプタの数を調べますか？
2. どのように数を増やしますか？
警告： 指定の際には、kern.maxfiles > kern.maxfilesperproc になるようにして下さい。
3. 指定できる上限はありますか？
私には良く判らないが、多分、カーネル内部には上限があると思う。 すべてのデータ構造は動的に割り当てられています。
他のBSD派生なOS（SunOS, 4.4BSD, OpenBSD, FreeBSD, NetBSD, BSD/OS, 386BSD, Ultrix)で数を増やす場合、カーネルの再構築が必要です。
１. どうやってファイルディスクリプタの数を調べますか？
2. どのように数を増やしますか？
3. もっと正確に指定できますか。
例えばSunの場合、usr/kvm/sys/conf.common/param.c/ttでこのような式になっています。
そしてNPROCは次のように定義されています。
Sunと同じようにusr/src/sys/conf/param.cを見てmaxusersとmaxfilesとmaxfilesperproc変数における関係を変えて下さい。
NPROCは次のように定義されています。
プロセスあたりの上限は、カーネル設定ファイルのoptions OPEN_MAX=128 で設定されているのでこれを調整します。
/usr/src/sys/conf/param.cのmaxfilesを編集してください。
NPROCは次のように定義されています。
プロセスあたりの上限は、カーネル設定ファイルのOPEN_MAX で設定されているのでこれを調整します。
変数の設定が終わったなら、カーネルを再構築してください。 再構築後に、こんどはSquidもconfigureし直してください。 そうしないと折角変更したファイルディスクリプタの上限数が反映されません。
例：
例えば以下のような表示がされます。：
これは正常なメッセージです。 これはcache_swap_highに達することなく、オブジェクトが廃棄された事を意味しています。 cachemgr.cgi （キャッシュマネージャ）を使って、以下の情報を調べてください。
この時間利用されなかったキャッシュは削除されます。 squidのconfigファイルのreference_age を指定することで、この時間を調整できます。
Windowsで次のように操作します：
[スタート] － [プログラム] － [Micrsoft インターネットサーバ] － [インターネットサービスマネージャ]
この中で、ftpに関するフォルダーのようなアイコンがあるのでここを開きます。 そしてFTPサーバのマシンを選び、右ボタンから[プロパティ]を選択します。 プロパティ画面の中に[ディレクトリ]という項目があるのでこれを選択します。 そしてディレクトリ形式として、UNIXとMS-DOSがあるのでUNIXを選択してください。
このアドレスの親または兄弟のキャッシュサーバから、（UDPでの）ICP MISSというメッセージを受け取っています。これは２つの状況が考えられます。
( RFC 952, RFC 1101) によって、下線の付いたホスト名は使ってはならないことになっています。
「名前」(ネット、ホスト、ゲートウェイ、あるいはドメイン名)は、アルファベット(A-Z)、数字（0-9)、マイナス記号(
- )、ピリオド( . )を使い字列最大２４文字。
DNS（bind)の最新バージョンのresolver ライブラリでは、ホスト名に下線があるとエラーとなります。 尤も良い解決策は、下線を使っているサイトの管理者に下線を使わないようにお願いしてください。
またcomp.protocols.tcp-ip.domains
FAQ. を参考にしても良いでしょう。
ある人は、RFC 1033 にて下線が許されているようだと報告してくるかも知れませんが、ここで述べられている例は、誤った例です。
上の回答を参照してください。下線のついたホスト名は使ってはいけません。 DNSによっては下線の利用を許しているかもしれません。 しかし、Squidでは許していません。 もしSquidでも許したいのなら、Squidをconfigureし直してください。
The answer to this is somewhat complicated, so please hold on. NOTE: most of this text is taken from ICP and the Squid Web Cache.
An ICP query does not include any parent or sibling designation, so the
receiver really has no indication of how the peer cache is configured to
use it. This issue becomes important when a cache is willing to serve cache
hits to anyone, but only handle cache misses for its paying users or customers.
In other words, whether or not to allow the request depends on if the result
is a hit or a miss. To accomplish this, Squid acquired the miss_access feature
in October of 1996.
The necessity of ``miss access'' makes life a little bit complicated, and not
only because it was awkward to implement. Miss access means that the ICP query
reply must be an extremely accurate prediction of the result of a subsequent
HTTP request. Ascertaining this result is actually very hard, if not impossible
to do, since the ICP request cannot convey the full HTTP request. Additionally,
there are more types of HTTP request results than there are for ICP. The ICP
query reply will either be a hit or miss. However, the HTTP request might result
in a ``304 Not Modified'' reply sent from the origin server. Such a
reply is not strictly a hit since the peer needed to forward a conditional
request to the source. At the same time, its not strictly a miss either since
the local object data is still valid, and the Not-Modified reply is quite small.
One serious problem for cache hierarchies is mismatched freshness parameters. Consider a cache C using ``strict'' freshness parameters so its users get maximally current data. C has a sibling S with less strict freshness parameters. When an object is requested at C, C might find that S already has the object via an ICP query and ICP HIT response. C then retrieves the object from S.
In an HTTP/1.0 world, C (and C's client) will receive an object that was never subject to its local freshness rules. Neither HTTP/1.0 nor ICP provides any way to ask only for objects less than a certain age. If the retrieved object is stale by Cs rules, it will be removed from Cs cache, but it will subsequently be fetched from S so long as it remains fresh there. This configuration miscoupling problem is a significant deterrent to establishing both parent and sibling relationships.
HTTP/1.1 provides numerous request headers to specify freshness requirements,
which actually introduces a different problem for cache hierarchies: ICP still
does not include any age information, neither in query nor reply. So S
may return an ICP HIT if its copy of the object is fresh by its configuration
parameters, but the subsequent HTTP request may result in a cache miss due to
any Cache-control: headers originated by C or by
C's client. Situations now emerge where the ICP reply no longer matches
the HTTP request result.
In the end, the fundamental problem is that the ICP query does not provide enough information to accurately predict whether the HTTP request will be a hit or miss. In fact, the current ICP Internet Draft is very vague on this subject. What does ICP HIT really mean? Does it mean ``I know a little about that URL and have some copy of the object?'' Or does it mean ``I have a valid copy of that object and you are allowed to get it from me?''
So, what can be done about this problem? We really need to change ICP so that freshness parameters are included. Until that happens, the members of a cache hierarchy have only two options to totally eliminate the ``access denied'' messages from sibling caches:
refresh_rules parameters.
miss_access at all. Promise your sibling cache
administrator that your cache is properly configured and that you will
not abuse their generosity. The sibling cache administrator can check his log
files to make sure you are keeping your word. If neither of these is realistic, then the sibling relationship should not exist.
（訳者から： スマン！よく判らん。）
要は、兄弟キャッシュにあるオブジェクトの鮮度がソースサーバの鮮度と同じだとは限らないことが原因になる可能性を指摘しているようです。 ICPにおいては、オブジェクトして兄弟キャッシュに存在するように見え、かつ、最新のような振りをしたオブジェクトが存在する可能性があるようです。
キャッシュサーバ間で、refresh_rulesを同じにすることと、miss_accessを使わないようにすることで、 "access
denied"を避けることができそうです。
すでに別のプロセスが、"8080"ポートを使っていることを意味します。 これは別のSquidがすでに動作しているか、あるいは別のプロセスが使っているかも知れません。
確認するには、
これは、LISTEN状態のプロセス（サーバプロセス）をすべて表示します。 この替わりに以下のように指定しても良いかも知れません。
いくつものプロセスあってどれがポートを押さえているか判らないなら、lsofというすばらしいソフトによってどのプロセスで確かめることができるでしょう。
Squidがデータを送っている最中にクライアントがソケットをクローズしたことを意味します。 Squidはread(2)関数を使ってこれを発見します。 普通に処理されてソケットがクローズされた場合にはECONNRESETという戻り値を受け取りますが、途中でクローズされた場合にはEPIPEを受け取ります。（EPIPE: Broken pipeとしてログcache.logに記録されます。）
Squid1.1では持続性ある接続をする不作法なクライアントからによって引き起こされます。 Squid1.1は持続性ある接続をサポートしません。
バージョン2.5以降ではマイクロソフトのNTLM認証をサポートします。このサポートには幾つかの限界が存在します。：NTLM認証を使うオリジナルサーバへのプロキシ接続はできません。しかし、WebアクセラレータとNTLMを使ったクライアント接続の認証にはNTLMを使う事ができます。
私たちはWindowsNT,Samba,Windows2000のドメインコントローラをサポートします。詳細についてはwinbind .を参照してください。
プロキシでNTLM認証が使えるにも係わらず、私たちはNTLMを公平には扱いません。 this
article:の記事のブラウザ認証に関する要約から：
Squidはクライアントとサーバ間のNTLMリクエストと応答ヘッダーを透過に通します。
NTLMはシングルエンド－エンド（訳者：ピア－ピアと訳した方が良いかも..）を期待しています。 これはプロキシを使ったNTLMを使う場合、プロキシはクライアントとサーバのリンクをしっかりと常に認識しておく必要がある事を意味します。 このような接続が機能するようにはしていますがプロキシの価値を低下させるものであることを私たちは理解しています。
NTLM認証はHTTPプロトコルに含ませて運びますが、しかしこれはHTTPのベーシック認証の方法と多くの点で違います。
多分、NetscapeでNTLM認証がサポートされることは無いでしょう：
以下のような親キャッシュの指定をしたとします：
しかし、UDPでもTCPでも親にはなにも送られません。
default を単純に加えてもすべてのリクエストが親に送られることを強いる事は無いでしょう。 default という意味は最後の手段としてこれで指定されたものを使うという意味で、すべてのリクエストのデフォルトという意味ではありません。 キャッシュは直接接続できるならdefault よりも優先されることでしょう。 もしあなたが親キャッシュを常に使うようにしたいならnever_direct オプションも使うようにしてください。
"HotMail"は同じIPアドレスから要求されるようになっている必要があり、階層のキャッシュを使うと接続に失敗します。以下のようにsquid.confを指定してください。
また、利用しているsquidのバージョンによっては、ダイレクトに接続するように設定すると良いかも知れません。
これは多分、あなたのシステムのメモリより多くのメモリをSquidが使っているからです。 Squidのプロセスで使うメモリが大きくなるとそれは多くのページングを行うことになり、急速にSquidのスピードを落とす結果につながります。 メモリの使い方は複雑な問題で多くの考慮すべき事項があります。
１つは、キャッシュマネージャを使い次の２つの情報を入手してください。
Number of HTTP requests received: 121104
Page faults with physical i/o: 16720
注意：もしあなたのシステムがgetrusage() 関数を持っていないなら、Page faultsの行を入手出来ないでしょう。
"Page faults with physical i/o"の数を"Number of HTTP requests
received"で割ってください。 （このケースでは、167200/121104=0.14)
理想的にはこの値は0.0～0.1の範囲になるべきです。 もし値が0.1～0.2の範囲であっても耐えられるかも知れません。 しかしこれ以上の値であるなら、あなたは多分Squidを遅く感じることでしょう。
もし比率が高いようなら、あなたは「Squidのメモリの使い方を削減するにはどうしますか？」を見てメモリの使用率を変える必要があるでしょう。
「私のSquidはどのくらいメモリを必要とするのでしょう？」も参照してください。
アクセス権の問題かも知れません。 Squidを実行しているUseridはdnsserver を実行する権限を有してますか？コマンドラインから次のように試してみると良いでしょう。
うまくいけば次のように表示される筈です。
バグデータベースでSquidのバグレポートを登録できるようになっています。 報告の際には以下の情報を含んでください。
バグレポートを送る前に、最新の安定版（STABLE)と開発版（development versions）のSquidで問題が解決するか確認してください。
Squidが異常終了してコアダンプを出力するであろう２つの条件があります。第１はSIGSEGV
か SIGBUS シグナルによってSquidを終了させた場合です。 第2は整合性チェックを含んでおり、そのチェックにかかった場合Squidの中でabort()
を呼び出すことでコアダンプを出力します。
多くの人がコアダンプが出ないと報告してきますが、それは以下の原因かも知れません。
# sysctl -w kern.sugid_coredump=1
次のような情報が表示されるならあなたのSquidはデバックシンボルをもっています。
と表示されます。
Squidの最近のバージョンでは、開始時にカレントディレクトリを報告してきます。 ここを最初に探してください。
もしカレントディレクトリにあるはずのコアダンプがないなら、Squidの起動ユーザのアクセス権がないかシェルでの限界になっている可能性があります。 シェルでリミットを指定するなら
コアダンプを採取できたらな、dbx や gdb といったデバッカーを使ってスタックトレースを生成します。：
可能なら１～２日間のコアダンプを保持すると良いでしょう。 このとき、複数のコアダンプは同じバイナリで作成されたものになるようにしてください。別の構成で作成されたバイナリのコアダンプを使った場合にはコアダンプの解析は混乱します。
もし、あなたが致命的でないバグ（例えば不適切なHTTP処理）を見つけたなら、どうか私たちに問題を説明するデバッッキングの為の cache.log
を送ってください。
cache.logはとても大きくなりますが、FTPまたはHTTPサーバを使ってサーバにコピーを送ってください。
Squidでデバッキング情報を有効にするのはとても簡単で、コマンドラインオプションで"-k debug"を付けて実行するだけです。
これにより、ソースコードに仕込まれたあらゆるdebug()文によってその情報がcache.logファイルに書き込まれます。 デバックをやめる場合は、オプションを元に戻すだけです。
選択的なデバックを行う場合（例えば１つのソースファイルだけ）には、Squid.confの debug_option の部分を編集してください。
Squidのソースファイルでは、あらゆる異なるデバックのセクションが割り当てられています。
デバックのセクションは各ソースの最初に割り当ててあり見ることができます。 または ソースファイルに付属する doc/debug-levels.txt で見ることができます。（Squid-2からは、このファイルの名前は debug-sections.txt になっています。） もしあなたが、デバッキング情報量を制御するならばデバックレベルを指定します。
最高レベルでは、多くのデバック情報が入手できます。 例えば、アクセス制御機能に関するすべてのデバック情報を取るなら、
として、Squidを再起動するかリコンフィグしてください。
一度、あなたはデバック情報をcache.logに取ってみてください。 そしてその振る舞いを確認し問題を理解すると良いでしょう。 難しいと感じたなら、どうぞsquid-users
か squid-bugs （訳者注：メーリングリスト？）にログを送ってください。
Squidは起動時にDNSによって自身の名前を取得しようと試みます。 もしこのメッセージが出るならその意味することは、
起動時のDNS検索を無効にするならSquidの起動時に-D オプションを使って起動してください。
また、squid.conf中で「visible_hostname」ディレクティブによって明示的にSquidの動作しているマシン名を定義しておく事で、このエラーを避けることができると思います。
注意： -D オプションは起動に際してのDNS検索を行わないだけで、Squidは内部的にDNSを利用しています。
バージョン1.1.15までは、最初に
を実行してSquidのスワップディレクトリを作っておく必要がありました。 もし、このときcache_effective_user を指定しているならSquidは指定したユーザIDでキャッシュディレクトリを作成しようとします。 その際、キャッシュディレクトリ（ex./var/spool/cache）は存在しないため、これを作成しようとしますが、これを作るアクセス権限を持っていないと"permission denied"となってエラーになります。 これを避けるには、単純で
とすれば良いでしょう。 （<userid> <groupid>は、cache_effective_user や cache_effective_group で指定したものかデフォルトのもの）
Squidがポートを開くためのアクセス権がないか、別のプロセスによってSquidの開くポートが使われているかのどちらかでしょう。 1024より小さいポートを開くためには、rootの権限が必要です。 もしSquidを開始するときにrootの権限を持っていないユーザで開始したならこのメッセージが表示されます。
また、既に別のプロセスがSquidが必要とするポートを使っている場合にもこの表示がされます。（例えばSquidをアクセラレータモードで起動する為、80のポートで開こうとしたが、すでに別のＷｅｂサーバが80を使っている場合など）
lsof ユーティリティを使うことで、だれがポートを使っているかを調べる事ができます。
この件は、リダイレクターの項目で述べています。
つぎの質問を参照してください。
Note：この情報はバージョン2.2以前のものに適用します。
Squidは利用できるディスクファイルの内容をビットマップとして持っています。 このビットマップのサイズは、２つのものによって確定します。１つはキャッシュのサイズ、もう一つはキャッシュオブジェクトの平均サイズです。
キャッシュのサイズは、squid.confのcache_dir で指定しています。 オブジェクトの平均サイズは、squid.confの'store_avg_object_size'
ディレクティブで指定できます。 デフォルトでは13Kbyteになっています。
squidはビットマップとして以下のサイズを割り当てます。
したがってもし正確にキャッシュオブジェクトの平均サイズを知っているなら、ビットマップファイルを50%になるように指定すると良いでしょう。 現在、どれだけビットマップ（ファイルマップ： Filemap）に使っているかは、キャッシュマネージャの'storedir' で知る事ができます。それは以下のように表示されます。
もし、"You've run out of swap file numbers"メッセージが表示されたなら、それは以下の２つの事を表しています。
あなたのキャッシュの平均サイズは、キャッシュマネージャの 'info' ページで知ることができます。
このワーニングメッセージがでたなら、'store_avg_object_size' 値を下げてSquidを再起動してください。
Note：この情報はバージョン2.3以上のものに適用します。
冷静になってください。これは正常です。 Squidは動的にオブジェクトの数を基にしてファイルマップ
ビットを割り当てます。動作中にファイルビットマップを使い果たさないことを私たちは約束します。
Unix（ライクのOS）では、プロセスとファイルには所有者が存在します。 プロセスの所有者は起動の際のユーザとなるため、常に変わる可能性があります。 もし、あなたがsquid.confでeffective_user でユーザを述べているなら、Squidはそのユーザで起動されるようになります。 このとき、ログファイルも同じユーザが所有者になっていないといけません。
これらのことはSquidではなくUnixのことを理解する必要があるので、もしこれだけで判らない場合にはUnixのリファレンスマニュアルを参照してください。
テストで次のようにアクセスしたとき
次のようなメッセージが表示されたなら
替わりに次のような指定をしてみてください。
これの意味するところは、あなたのpinger プログラムがroot特権を持っていないことを意味します。次のようにしてみてください。
または
フォワーディングループが発生するのは、同じプロキシにもう一度リクエストが要求されるからです。 これは
フォワーディングループは、リクエストヘッダのVia を調べることで見つけられます。 各キャッシュでは、リクエストのVia ヘッダに"touches"としてホスト名を加えます。 もしキャッシュがリクエストされてきたヘッダに自分の名前を見つければフォワードループがおきている事に気付くでしょう。
NOTE: ループを見つけられるように、キャッシュのホスト名にはそれぞれ別の名前を与えるようにしてください。 もし、squid.confでvisible_hostname として複数のキャッシュに同じ名前を与えているなら、unique_hostname でそれぞれにユニークな名前を与えなくてはいけません。
Squidがフォワーディングループを見つけたなら、cache.log ファイルにVia ヘッダとともに記録されます。 この情報からどのキャッシュがフォワードしてきたかを調べることができるでしょう。
ループを解消するには、親子（parent）から兄弟関係（ibling）に関係を変更することです。
別の方法としては、cache_peer_access を使ったルールを作ることです。 例として、
上記の構成は、フォワードリクエストでないリクエストのみをA,B,Cのいずれかの親にリクエストするようになります。
このエラーはたいがいSolarisシステムで見られます。 Mark Kennedy は重要な報告を行っています。
cacheログでこれらのメッセージが記録されました。 わたしはディスク上のインデックスコンテンツとコンテンツがマッチしないのだと推測しています。
Squidはどうなっているのですか？
注意：これはSquid-2に特有です。キャッシュにヒットしたオブジェクトをディスクから読み込むとき、そのサイズが期待したもので無いとき、このメッセージが記録されます。 この場合Squidはディスクにあったオブジェクトはクライアントには送らず、再びソースサーバからオブジェクトを入手きます。
これらのメッセージはバギー（バグだらけな）クライアント、主としてNetscape Navigator（ネットスケープ）によって引き起こされます。Netscapeの持続性のあるHTTPS/SSLリクエストを送るときにこれは発生します。普通、SquidはSSLの接続要求としてつぎのようなものを受け付けます。
このときSquidは受け取ったリクエストによって、相手先のホストとポートへ暗号化されたそのままの接続要求を送ります。 このポイントはSSLの要求はすべて暗号化されたそのままで送られることです。バグのあるクライアントからは次ぎような接続がきます。
このとき、ヘッダーとメッセージボディは暗号化されておらずに送られてきました。 SquidにはこれをSSL要求として変える如何なる方法もありません。我々にできることはエラーメッセージを返すことだけです。
Note： このバグはブラウザが暗号化せずにデータをおくってくるので本当に危険なバグです。
Dave J Woolley による：
これらは、不法のサイトによって使われた不法のURLです。この目的は、
いくつかのブラウザとプロキシでは機能するため、セキュリティリスクを良く考慮してください。
URIとURLには余白キャラクター(スペース、タブ、newline、改行キー)の使用が許されていません。 残念ながら多くのWebサイトで空白をもつURLを使っています。 もちろんあなたのお気に入りのブラウザが静かにこれらの悪URLを正しく適用させています。 これらの空白キャラクタはインターネット標準に違反するので符号化されるべきです。
Squidでは空白キャラクタの取り扱いをuri_whitespace で決定できます。これには４つの指定が可能です。
これは、多分あなたのシステムがloopbackネットワーク・デバイスを持たない、またはデバイスが適切に構成されないということを意味します。すべてのUnixシステムは、lo0と呼ばれるネットワーク・デバイスを持っているべきです。そして、それは、アドレス127.0.0.1で構成されます。構成を以下のコマンドで調べてください。
結果は以下のようになる筈です。
FreeBSDを使っているならここを見てください。
cache_dir のがバージョン2.3から変わりました。 それは現在、type 引数を必要になりました。すべての使えるように以下のように指定してください。
Squid2.3現在では、デフォルトでDNS検索に内蔵コードを使います。 この場合、squid.conf でcache_dns_program と dns_children オプションで明示的に指定する必要はありません。 通常はコメントアウトにしておいて構いません。 あなたが外部のDNSサーバが持っているDNS検索プログラムを使いたい場合、configureを実行する際に次のようにしてください。
Squid2.3以降、デフォルトでは内蔵のDNS検索が使われます。 dns_defnames は外部のdnsserverプロセスの為に使われます。 もしdns_defnames を指定するならその前に、３つの選択をしておきます：
search と domain が /etc/resolb.conf から取り出せるようにしてください。"Connection reset by peer"はUnixオペレーティングシステムで、read, write, connect,およびその他のシステムコールで時々戻されるエラーコードです。
他のホスト・仲間と接続中に仲間がＴＣＰ接続でリセットパケットを送ったことを意味します。 これは実在しない接続において思いがけないパケットを受けたときなどに発生します。
これらのログがSquidのログに残るということは、オリジナルサーバや親サーバが壊れたことを意味します。 一方、これはいたってあり得る事で、適切な終了をせずに処理を強制終了することはあり得ることです。
このメッセージはあまり心配する必要はありません。
接続を試みようとしたサーバがいないときに、接続しようとしたポートへの接続に対するオペレーティングシステムから返されるエラーメッセージです。
このメッセージを簡単に再現する方法として、適当なポート番号を指定したtelnetとして以下のような接続を行うと再現できるでしょう。
ポート12345で待ち受けているサーバがいない限り上記のようなエラーが再現できます。
このエラーが表示されるということは、サーバが存在しないか、一時的に接続できない状態のどちらかです。
この方法で、Squidは再度設定ファイルを読み込むともにsquid.pidを作成します。
多分あなたはrootでSquidを起動したと思います。 Squidは特別な特権を持たないグループIDで起動しようとします。 通常これにはグループIDのnogroupが使われます。 しかし、あなたのシステムにはnogroupというグループIDが登録されてなかもしれません。この場合このようなエラーメッセージが表示されます。 cache_effective_group を使って/etc/groupに登録されてい実際のグループIDを指定してください。
Note：これはバージョン2.3以上に適用できます。
これは正しい動作です。 SquidはHTTPSのURLが指定されたとき、SSLのパケットを話す必要がありますが出来なかった事を意味します。
これは２つのパターンで起こります。
数多くの原因が考えられます。
Andrew Doroshenko のレポートでは、/dev/nullの削除・nodev オプションをを使ったファイルシステムのマウントでSquidがCUPを100%使い切ることを報告しています。 彼の示唆では、"/dev/null"を触ることに何か問題がありそうです。
Mikael Andersson のレポートでは、Webminのcachemgr.cgi をクリックするとcachemgr.cgi の多数のインスタンスが作成され利用できるメモリを消費してシステムを破壊します。
Joe Cooper のレポートでは、これは幾つかのブラウザ（主としてNetscape6、Mozilla）のSSLの問題で引き起こされることを報告しています。Netscape4やMicrosoft IEといった別のブラウザで試みるかSSL暗号化を無効にしてください。
幾つかのGCCのバージョン（特に2.95.1から2.95.4まで）にはコンパイラーの最適化の部分にバグがあります。 これらのバグはSquidにおいてNULLポインタを指すバグを起こします。結果として、"FATAL: Received Segment Violation...dying'' を引き起こし、コアダンプをはき出して死んでしまいます。
これらのバグを避けるには、コンパイルで最適化を行わないようにしてください。 尤もよい方法はソースのコンパイルの際に明確にCCのオプションを指定することです。
このconfigureが正しく作成できたか調べるには、AC_CFLAGS をsrc/Makefile から検索して以下の行を求めてください。
この後、再コンパイルすることで最適化しないでコンパイルが実行されます。
Note：最適化せずにコンパイルすることでSquidのパフォーマンスを心配する人がいますが、これによるSquidへのインパクトは殆ど影響ないか、全く影響内定度軽微です。
fnac.net のYomler によると、
良くない設定のInternet Explorerと、cydoor DLLを使う幾つかのアプリケーションを組み合わせると、このメッセージがログに記録されます。詳しくは、cydoor.com の修正リストを見てください。
良くない設定のIEとは、動的な構成スクリプト（proxy.pac）と一緒に、普通のプロキシ指定もする設定です。 この時、IEがproxy.pacを使うように設定されいても、Cydoor ASPでは両方の設定を使うようになって、エラーを生み出します。
IEのプロキシの設定を無効にするだけではなく、設定フィールドの中を完全にクリアし、かつproxy.pacだけを使うようにしてください。
国際化ドメイン名はＨＴＴＰ標準化グループによってまた一致した見解が出ていません。 完全に一致した見解がでたならSquidでもサポートします。
国際的なドメイン名のための標準化プロセスの進歩に興味があればIETF IDNワーキング・グループのページを見てください。
Squidがソースサーバに接続するときに、これが発生することがあります。 推理すると、Squidがデータを読もうとしたときに接続を絶たれてしまうのだと思います。 様々な要因によって、Squidはリトライを継続することができません。 もし、”Zero Sized Reply'' となったなら、Squidが再接続することができなかったか、リトライの試みを失敗したことを意味します。
何が原因として考えられるか：
問題を観測するためには、tcpdump を使うのも効果的です。
何人かの人は、問題がとても大きなクッキー（cookie）によって引き起こされていると信じています。 ある人は彼のIEからサードパーティのクッキーを受け入れないようにした結果この問題が解決したといっています。
Zero Sized Reply エラーをなくすためにあなたが試すことができる幾つかの事柄があります。
これらで解決できず、Zero Sized エラーがあなたにとって深刻なら、Squid開発陣はあなたの問題解決を助けることができます。 そのためには、あなたからHTTPヘッダーを含んだtcpdumpの情報やサーバのIPアドレス、オペレーティングシステムのバージョン、access_logなど多くの情報が必要です。
もしオンデマンドでZero Sized エラーをSquidに与えたければ、以下の小さなプログラムを作成してポート80が動いていないマシン上で実行させることで偽のサーバとして機能させることができます。これを使ってSquidから接続を試みると良いでしょう。
#include <stdio.h>
#include <stdlib.h>
#include <unistd.h>
#include <sys/types.h>
#include <sys/socket.h>
#include <netinet/in.h>
#include <arpa/inet.h>
#include <assert.h>
int
main(int a, char **b)
{
struct sockaddr_in S;
int s,t,x;
s = socket(PF_INET, SOCK_STREAM, 0);
assert(s > 0);
memset(&S, '\0', sizeof(S));
S.sin_family = AF_INET;
S.sin_port = htons(80);
x = bind(s, (struct sockaddr *) &S, sizeof(S));
assert(x == 0);
x = listen(s, 10);
assert(x == 0);
while (1) {
struct sockaddr_in F;
int fl = sizeof(F);
t = accept(s, (struct sockaddr *) &F, &fl);
fprintf(stderr, "accpeted FD %d from %s:%d\n",
t, inet_ntoa(F.sin_addr), (int)ntohs(F.sin_port));
close(t);
fprintf(stderr, "closed FD %d\n", t);
}
return 0;
}
カーネルが認識できる１ファイルあたりの最大ファイルサイズを確認してください。（Ｌｉｎｕｘ2.2では2GBまでです） このサイズの上限にログファイルが達してませんか？ ログは通常は/var/log/squidディレクトリ以下に作成されます。
もし上限に達しているならば、ログのローテーションの設定を行って、１ファイルのサイズが小さくなるようにしてください。
WindowsXPにSP2を適用以後、WindowsUpdateができなくなる場合があります。 これは、SP2にてWindowsUpdateが使っている転送プログラム（BITS）が更新され、これがIEで指定されているプロキシの情報を使っていないために、直接、インターネットにアクセスしようとするために発生します。
BITSにプロキシを認識させるためには、IEの設定を引き継ぐために
を実行すると良いでしょう。
参考：