Squid на сервере: частые ошибки и решения

MAATRIX

Squid — мощный прокси, но его гибкость оборачивается типовыми ошибками: Access Denied из-за неверного порядка ACL, отказ авторизации, падение сервиса из-за опечатки в конфиге. Ниже — частые ошибки Squid на сервере, разобранные по симптомам и строкам в логах, с командами, которые показывают причину сразу, а не заставляют читать весь конфиг подряд.

Где искать причину

Squid ведёт два ключевых журнала: access.log — что запрашивали клиенты и с каким результатом, и cache.log — что происходило с самим сервисом. При любой проблеме начинайте с них и со статуса сервиса:

systemctl status squid
tail -n 40 /var/log/squid/cache.log
tail -n 40 /var/log/squid/access.log

В access.log для каждого запроса стоит код результата: TCP_MISS/200 — всё хорошо, запрос прошёл; TCP_DENIED/403 — доступ закрыт правилами; TCP_DENIED/407 — требуется авторизация, но клиент её не прошёл. Уже по коду понятно, куда смотреть: 403 отправляет вас в ACL, 407 — в настройки аутентификации. Такой подход быстрее любого гадания: сначала читаем, что именно ответил Squid, потом чиним конкретную причину.

Полезно держать под рукой ещё одну команду — просмотр лога в реальном времени. Запустив tail -f /var/log/squid/access.log и повторив проблемный запрос с клиента, вы видите, как Squid реагирует прямо сейчас, а не разбираете историю задним числом. Это особенно ценно, когда проблема плавающая: одни запросы проходят, другие нет. По полю с доменом и коду ответа сразу видно, на каких именно адресах Squid спотыкается, и это резко сужает круг поиска.

Access Denied на всё подряд

Самая частая ошибка новичков — прокси отвечает Access Denied на любой запрос. В 90% случаев виноват порядок правил http_access. Squid читает их сверху вниз и применяет первое подходящее, поэтому если строка http_access deny all стоит выше разрешающих, доступ закрыт для всех ещё до того, как Squid дойдёт до allow. Проверьте порядок: сначала все allow, и только в самом конце deny all. Второй источник — вы убрали стандартные ACL, но не добавили своё разрешающее правило, и прокси по умолчанию всё запрещает. Всегда проверяйте конфиг перед перезапуском:

squid -k parse

Команда покажет синтаксические ошибки и не даст сервису упасть от опечатки. Если parse молчит, а Access Denied остаётся, дело именно в логике ACL, а не в синтаксисе.

Сервис не запускается

Squid не стартует или падает сразу после запуска. Смотрите cache.log — там причина написана прямым текстом. Частые случаи: опечатка в директиве, ссылка на несуществующий файл (например, неверный путь к файлу паролей или к хелперу авторизации), занятый порт. Если Squid жалуется на порт, найдите, кто его держит:

ss -lntp | grep 3128

Ещё одна частая причина падения при первом запуске или после смены каталога кэша — неинициализированный кэш. Squid нужно один раз создать структуру каталогов кэша при остановленном сервисе:

systemctl stop squid
squid -z
systemctl start squid

Если сервис падает после правки, откатитесь на сохранённую копию конфига и вносите изменения по одному — так проще найти строку, которая всё ломает.

Авторизация не работает

Клиент вводит логин и пароль, а Squid всё равно отвечает 407 или отклоняет доступ. Проверьте три вещи. Первое — путь к хелперу в auth_param: на разных системах basic_ncsa_auth лежит в разных каталогах, и неверный путь ломает авторизацию молча. Второе — файл паролей: он должен существовать, быть читаемым для Squid и создан именно htpasswd. Третье — наличие правила, которое связывает авторизацию с доступом: acl authenticated proxy_auth REQUIRED и http_access allow authenticated. Без разрешающего правила даже верный пароль не даст доступа. После правок обязательно перезапустите сервис, иначе Squid работает со старым конфигом.

Ещё одна тонкость связана с браузерами и приложениями: некоторые из них кэшируют неудачную попытку авторизации и продолжают слать старые данные, даже когда вы уже поправили пароль. Если уверены, что конфиг верный, а 407 не уходит, проверьте на «чистом» клиенте — например, тем же curl с явно указанными логином и паролем. Если через curl доступ есть, проблема на стороне клиентского приложения, а не Squid, и лечится сбросом сохранённых учётных данных или перезапуском клиента.

Снаружи не подключается

С сервера прокси отвечает, а снаружи соединение висит. Сначала убедитесь, что Squid слушает внешний адрес, а не только localhost:

ss -lntp | grep squid

Если в http_port указана привязка к 127.0.0.1, снаружи прокси недоступен. Уберите привязку или укажите нужный адрес. Дальше — фаервол: порт должен быть открыт и в ufw, и, что критично, в security groups облачной панели. Про внешний фаервол облака забывают чаще всего, и именно он даёт вечно висящее соединение при рабочем сервисе. Проверяйте доступ снаружи с другой машины запросом через curl с логином и паролем.

Медленно, кэш и репутация IP

Если прокси работает, но медленно, причин несколько. Забитый диск кэша тормозит Squid — проверьте df -h и при необходимости очистите или пересоздайте кэш. Медленный или недоступный DNS даёт задержки на резолвинге имён; проверьте резолверы сервера. Если же часть сайтов отдаёт капчу или блокировки, это не про Squid, а про репутацию IP: засвеченный адрес будет вызывать подозрение независимо от настроек. Для задач, где важна чистота адреса, нужен VPS с незапятнанным IP — у MAATRIX его можно арендовать в США, Европе или России с оплатой из России картой, СБП или криптой, что снимает вопрос и с адресом, и с оплатой зарубежного сервера.

Подводя итог, большинство ошибок Squid укладывается в три группы: логика ACL, авторизация и фаервол. Если запомнить, что правила читаются по порядку и deny all идёт последним, что авторизация требует и хелпера, и файла паролей, и разрешающего правила, и что порт надо открывать в двух местах — в системе и в облаке, — вы закроете подавляющую часть проблем ещё до того, как они возникнут. А привычка сначала читать код ответа в access.log, а уже потом что-то менять, превращает отладку из гадания в короткую последовательность понятных шагов.

Частые вопросы