11.11 Cannot bind socket fd nn to *:8080 (125) Address already in use

Это значит, что другой процесс уже слушает порт 8080 (или тот, что вы используете). Это может значить, что процесс Squid уже запущен или это сделала другая программа. Чтобы порверить, используйте команду netstat:

netstat -naf inet | grep LISTEN

Она покажет вам все сокеты находящиеся в состоянии LISTEN. Можете также попробовать

netstat -naf inet | grep 8080

Если вы обнаружили, что како-то процесс занял ваш порт, но неуверены, что это за процесс, то можете использовать отличную программу lsof. Она покажет вам каждого владельца открытого дескриптора файлов в вашей системе.

11.12 IcpDetectClientClose: error XXX.XXX.XXX.XXX: (32) Broken pipe

Это значит что клиентский сокет был закрыт клиентом до того как Squid закончил пересылку данных в него. Squid определяет это, пытаясь получить от сокета данные при помощи read(2). Если вызов read(2) неудачен, то Squid определяет, что сокет был закрыт. Обычно вызов read(2) возвращает ECONNRESET: Connection reset by peer и это НЕ фиксируется в логе. Любые другие сообщения об ошибках (такие как EPIPE: Broken pipe) записываются в cache.log. Посмотрите ``intro'' раздела 2 руководства по вашей Unix, чтобы получить список всех сообщений об ошибках.

11.13 IcpDetectClientClose: fd 135, 255 unexpected bytes

Это происходит по вине некоторых "кривых" Web-клиентов, которые пытаются использовать постоянные соединения. Squid-1.1 не поддерживает постоянные соединения.

11.14 Does Squid work with ntlm Authentication?

Version 2.5 will support Microsoft NTLM authentication. However, there are some limits on our support: We cannot proxy connections to a origin server that use NTLM authentication, but we can act as a web accelerator or proxy server and authenticate the client connection using NTLM.

Нами поддерживается NT4, Samba и контроллеры домена Windows 2000. Для более подробной информации загрузите squid 2.5 и запустите ./configure --help.

Why we cannot proxy NTLM even though we can use it. Quoting from summary at the end of the browser authentication section in this article:

In summary, Basic authentication does not require an implicit end-to-end state, and can therefore be used through a proxy server. Windows NT Challenge/Response authentication requires implicit end-to-end state and will not work through a proxy server.

Squid transparently passes the NTLM request and response headers between clients and servers. NTLM relies on a single end-end connection (possibly with men-in-the-middle, but a single connection every step of the way. This implies that for NTLM authentication to work at all with proxy caches, the proxy would need to tightly link the client-proxy and proxy-server links, as well as understand the state of the link at any one time. NTLM through a CONNECT might work, but we as far as we know that hasn't been implemented by anyone, and it would prevent the pages being cached - removing the value of the proxy.

NTLM authentication is carried entirely inside the HTTP protocol, but is different from Basic authentication in many ways.

1. It is dependent on a stateful end-to-end connection which collides with RFC 2616 for proxy-servers to disjoin the client-proxy and proxy-server connections.

2. It is only taking place once per connection, not per request. Once the connection is authenticated then all future requests on the same connection inherities the authentication. The connection must be reestablished to set up other authentication or re-identify the user.

The reasons why it is not implemented in Netscape is probably:

• It is very specific for the Windows platform

• It is not defined in any RFC or even internet draft.

• The protocol has several shortcomings, where the most apparent one is that it cannot be proxied.

• There exists an open internet standard which does mostly the same but without the shortcomings or platform dependencies: digest authentication.