Прокси-серверы: Часть 6 — Squid

Squid — свободный HTTP-прокси с кешированием, один из старейших прокси-серверов, которые развиваются до сих пор. Он работает как прямой прокси для пользователей сети, умеет кешировать ответы веб-серверов, проверять пользователей, фильтровать адреса и вести подробный журнал запросов. Может Squid работать и как обратный прокси перед веб-сервером, но для этой задачи сегодня обычно выбирают Nginx или HAProxy.

Версии

Актуальная ветка — Squid 7. На сентябрь 2026 года последняя версия — 7.7, выпущенная 24 августа 2026 года. Разработчики поддерживают только последнюю стабильную версию, более старые ветки сопровождают дистрибутивы. В Debian 12 поставляется Squid 5.7, в Debian 13 — 6.13, в тестовой ветке — 7.7.

В Squid 6 удалена поддержка протокола Gopher: такие запросы теперь обрабатываются как запросы с неизвестным протоколом. Упоминания Gopher в старых руководствах можно не учитывать.

Почему кеширование уже не главное

Squid создавался в то время, когда большая часть сайтов работала по HTTP, а каналы связи были медленными и дорогими. Прокси, который отдавал сотне пользователей одну и ту же картинку из своей памяти, заметно экономил трафик.

Сейчас почти все сайты работают по HTTPS. Для такого соединения браузер отправляет прокси команду CONNECT с именем сайта и портом, после чего прокси только передаёт зашифрованные данные между браузером и сервером. Содержимого он не видит и закешировать его не может. Кроме того, многие страницы формируются под конкретного пользователя и помечены сервером как некешируемые.

Кеш Squid по-прежнему полезен там, где трафик идёт по HTTP и повторяется: например, при обновлении пакетов на множестве серверов из зеркал, работающих по HTTP (целостность пакетов проверяется подписью). Но для этой узкой задачи есть и специализированные программы вроде apt-cacher-ng.

Основная ценность Squid сегодня — контроль доступа, авторизация пользователей и учёт веб-трафика. Даже при HTTPS прокси видит, к какому сайту обращается пользователь, сколько данных передано и когда.

Установка

В Debian и Ubuntu:

sudo apt install squid apache2-utils

Пакет apache2-utils нужен для утилиты htpasswd, которой создаётся файл паролей. Конфигурация находится в /etc/squid/squid.conf, журналы — в /var/log/squid/.

Конфигурация с авторизацией и фильтрацией

Ниже — конфигурация для офиса: прокси на порту 3128, доступ только из локальной сети и только по паролю, запрет на отдельные сайты и небольшой кеш.

http_port 3128

auth_param basic program /usr/lib/squid/basic_ncsa_auth /etc/squid/passwords
auth_param basic children 5
auth_param basic realm Proxy
auth_param basic credentialsttl 1 hour

acl localnet src 192.168.0.0/16
acl SSL_ports port 443
acl Safe_ports port 80 443
acl CONNECT method CONNECT
acl auth proxy_auth REQUIRED
acl blocked dstdomain .example.com .example.org

http_access deny !Safe_ports
http_access deny CONNECT !SSL_ports
http_access deny blocked
http_access allow localnet auth
http_access deny all

cache_mem 256 MB
cache_dir ufs /var/spool/squid 10000 16 256
maximum_object_size 200 MB

Как это устроено:

• auth_param подключает программу проверки паролей basic_ncsa_auth, которая читает файл в формате htpasswd;
• acl задаёт именованные условия: адреса клиентов (src), порты, метод CONNECT, требование авторизации (proxy_auth REQUIRED), домены назначения (dstdomain; точка в начале означает «домен и все поддомены»);
• http_access — правила доступа. Они проверяются сверху вниз, срабатывает первое подходящее, поэтому запреты стоят выше разрешений, а последняя строка deny all закрывает всё остальное;
• deny CONNECT !SSL_ports не позволяет использовать прокси как туннель на произвольные порты — это стандартная защита из конфигурации по умолчанию;
• cache_mem — объём кеша в памяти, cache_dir — кеш на диске (10 000 МБ), maximum_object_size — самый большой объект, который будет сохраняться.

Фильтр dstdomain работает и для HTTPS: в команде CONNECT прокси получает имя сайта, поэтому блокировать домены можно без расшифровки трафика.

Пользователи и проверка:

sudo htpasswd -c /etc/squid/passwords ivan
sudo htpasswd /etc/squid/passwords olga
sudo squid -k parse
sudo systemctl restart squid
curl -x http://ivan:ПАРОЛЬ@192.0.2.10:3128 https://example.net -I

Ключ -c создаёт файл, поэтому для второго и следующих пользователей его не указывают. Команда squid -k parse проверяет конфигурацию до перезапуска, а после небольших правок вместо перезапуска достаточно squid -k reconfigure.

Настройка клиентов

• Компьютеры сотрудников. Прокси задаётся в системных настройках сети, и браузеры берут его оттуда. В сети с Active Directory адрес прокси распространяется групповыми политиками. Для гибких правил (какие адреса идут через прокси, а какие напрямую) используют файл автоматической настройки PAC.
• Серверы и консольные программы. Большинство утилит понимают переменные окружения http_proxy и https_proxy, например https_proxy=http://ivan:ПАРОЛЬ@192.0.2.10:3128. Для apt прокси задаётся отдельно, строкой Acquire::http::Proxy "http://192.0.2.10:3128"; в файле из каталога /etc/apt/apt.conf.d/.
• Исключения. Внутренние адреса и сервисы в локальной сети обычно отправляют напрямую, минуя прокси: переменная no_proxy или соответствующее поле в системных настройках.

Учёт трафика

Каждый запрос записывается в /var/log/squid/access.log: время, длительность, адрес клиента, результат, объём ответа, метод, адрес и имя пользователя. По полю результата видно, что произошло с запросом:

• TCP_TUNNEL — HTTPS-соединение через CONNECT, прокси только передавал данные;
• TCP_MISS — объекта не было в кеше, он получен с сервера;
• TCP_HIT и TCP_MEM_HIT — ответ отдан из кеша;
• TCP_DENIED — запрос запрещён правилами.

Из журнала строятся отчёты по пользователям и сайтам — вручную или с помощью анализаторов журнала Squid, например SARG. Ограничивать скорость для пользователей или групп позволяют пулы задержки (delay_pools).

SslBump: расшифровка HTTPS

Чтобы кешировать и фильтровать содержимое HTTPS-страниц, а не только имена сайтов, в Squid есть механизм SslBump. Прокси встаёт посередине: расшифровывает соединение, проверяет содержимое и снова шифрует его сертификатом, который выпускает сам. Чтобы браузеры не выдавали предупреждений, корневой сертификат прокси нужно установить на все клиентские устройства. В Debian для этого нужен пакет squid-openssl.

С версии 3.5 в Squid есть режим peek-and-splice. Прокси «подглядывает» в начало TLS-соединения, где передаётся имя сайта (SNI), и решает, что делать дальше: расшифровать соединение (bump), пропустить его без расшифровки (splice) или разорвать. Правило ssl::server_name позволяет, например, пропускать без расшифровки банки и государственные сервисы.

Прежде чем включать расшифровку, стоит взвесить последствия:

• Закон и этика. HTTPS создан для того, чтобы переписку пользователя никто не читал. Документация Squid прямо предупреждает, что расшифровка HTTPS без согласия и ведома пользователей может нарушать этические нормы и закон. В компании это допустимо только при утверждённой политике и уведомлении сотрудников, а личные устройства расшифровывать не следует.
• Безопасность. Прокси с закрытым ключом корневого сертификата становится самым ценным объектом в сети: его взлом открывает весь трафик.
• Совместимость. Приложения, которые проверяют сертификат сервера жёстко (закрепление сертификата), через расшифровывающий прокси работать перестанут.

Если нужно только блокировать сайты по имени, расшифровка не требуется: хватает dstdomain в режиме явного прокси или ssl::server_name с действием splice.

Типичные ошибки

• Правило разрешения стоит выше запрета. Squid останавливается на первом подходящем http_access, поэтому deny blocked ниже allow localnet не сработает.
• Нет строки http_access deny all в конце. Если ни одно правило не подошло, Squid применяет действие, противоположное последнему правилу в списке. Поведение становится неочевидным, поэтому последнее правило всегда пишут явно.
• Открытый прокси. Разрешение allow all без ограничения адресов превращает сервер в открытый прокси, который быстро находят и используют посторонние.
• Кеш не инициализирован. После добавления cache_dir каталоги кеша создаёт команда squid -z; в Debian это делает сценарий запуска службы, но при ручной установке шаг легко пропустить.
• Пароль передаётся открытым текстом. Базовая авторизация передаёт пароль без шифрования. Внутри офисной сети это обычно приемлемо, через интернет — нет.

Достоинства и ограничения

Достоинства:

• гибкие правила доступа по адресам, пользователям, доменам, времени и типам содержимого;
• авторизация через файл паролей, LDAP и Active Directory;
• подробный журнал запросов и готовые анализаторы для отчётов;
• ограничение скорости через пулы задержки;
• зрелый проект с обширной документацией.

Ограничения:

• кеширование мало помогает при HTTPS, а для полноценной работы с HTTPS нужна расшифровка со всеми её последствиями;
• большой и не самый простой файл конфигурации;
• как обратный прокси и балансировщик уступает Nginx и HAProxy;
• кеш на диске требует места и памяти.

Когда выбирать Squid

Squid подходит, когда в сети нужно пускать сотрудников в интернет по паролю, запрещать отдельные сайты и получать отчёты о том, кто и сколько обращался к каким ресурсам. Если нужен лишь SOCKS5-прокси для приложений — проще Dante; если нужны HTTP- и SOCKS-прокси с лимитами трафика для нескольких пользователей — 3proxy.