Установка HTTPS-прокси на Linux через Squid: рабочая схема без ловушек

Фраза «HTTPS-прокси на Squid» часто означает две разные вещи. Первая и самая частая задача выглядит так: клиент подключается к Squid как к обычному proxy, а сам Squid пропускает HTTPS-сайты через CONNECT-туннель. Вторая задача сложнее: шифруется не только трафик к сайтам, но и соединение между клиентом и самим прокси. Для такого режима в Squid нужна директива https_port, а в официальной документации Squid прямо сказано, что для неё обязателен tls-cert.

Ниже дам обе схемы, но начну с той, которая реально нужна большинству. Сначала поднимем нормальный forward proxy с аутентификацией и ограничением по IP. Потом, если нужен именно HTTPS-прокси в узком смысле слова, добавим TLS на стороне Squid. Такой порядок полезен не только для новичка. Даже опытные админы часто начинают с сертификатов, а потом неделями ловят банальную ошибку в ACL или в пути к basic_ncsa_auth.

Используйте прокси только в своей инфраструктуре, с согласия пользователей и в рамках местного законодательства. Перехват чужого трафика, прозрачное проксирование без уведомления и особенно дешифровка HTTPS через ssl_bump без явной необходимости могут создать не только технические, но и юридические проблемы.

Что такое HTTPS-прокси на Squid и какой режим выбрать

Если нужен личный прокси на VPS, почти всегда хватает обычного http_port. Клиент подключается к Squid по HTTP-протоколу прокси, а доступ к HTTPS-сайтам идёт через CONNECT. Сам сайт остаётся зашифрованным, Squid не расшифровывает содержимое страниц и не лезет в сертификаты сайта.

Режим с https_port нужен в другом сценарии: когда вы хотите зашифровать канал «клиент → прокси». На практике такой вариант полезен, если не хочется светить логин и сам факт работы с прокси в локальной сети или у провайдера. Но здесь есть нюанс: поддержка HTTPS-прокси у разных клиентов неидеальна. Поэтому сначала лучше поднять обычный прокси на 3128, проверить логику доступа, и только потом добавлять TLS-порт, например 3129.

Установка Squid на Ubuntu, Debian, Rocky и AlmaLinux

Сначала обновите систему и поставьте сам Squid плюс утилиту htpasswd для создания пароля. На Debian и Ubuntu пакет с TLS-функциями иногда идёт отдельной сборкой. В Debian Wiki прямо указано, что доступны и squid, и squid-openssl. Поэтому после установки сразу проверьте, чем собран ваш бинарник.

Ubuntu и Debian

sudo apt update
 sudo apt install squid apache2-utils -y
 sudo systemctl enable --now squid
 sudo squid -v | grep -Ei 'openssl|gnutls'

Если вы планируете использовать https_port, а в выводе нет OpenSSL или GnuTLS, замените пакет:

sudo apt remove squid -y
 sudo apt install squid-openssl apache2-utils -y
 sudo systemctl enable --now squid
 sudo squid -v | grep -Ei 'openssl|gnutls'

Rocky, AlmaLinux, RHEL

sudo dnf install squid httpd-tools -y
 sudo systemctl enable --now squid
 sudo squid -v | grep -Ei 'openssl|gnutls'

Сразу сохраните резервную копию конфига:

sudo cp /etc/squid/squid.conf /etc/squid/squid.conf.bak

Настройка аутентификации и безопасного доступа в Squid

Открытый прокси в интернете живёт недолго. Его быстро находят сканеры, после чего сервер превращается в мусоропровод для спама, перебора и чужих запросов. Поэтому базовый минимум выглядит так: пароль плюс ограничение по IP. Один пароль без ограничения по IP уже лучше, чем ничего, но для публичного VPS слабоват.

Найдите путь к helper для NCSA-аутентификации. На разных дистрибутивах он отличается, поэтому лучше не гадать:

find /usr -type f -name basic_ncsa_auth 2>/dev/null

Обычно путь выглядит как /usr/lib/squid/basic_ncsa_auth или /usr/lib64/squid/basic_ncsa_auth. Дальше создайте файл с паролями:

sudo touch /etc/squid/passwd
 sudo chown root:root /etc/squid/passwd
 sudo chmod 600 /etc/squid/passwd
 sudo htpasswd -B /etc/squid/passwd alice

Команда попросит ввести пароль для пользователя alice. Повторить можно сколько угодно раз, чтобы добавить новых пользователей.

Готовая безопасная конфигурация Squid для HTTPS-сайтов через CONNECT

Ниже минимальный конфиг для личного прокси. Он не включает кэширование, не включает перехват HTTPS, требует пароль и пускает только указанные IP-адреса. Замените путь к basic_ncsa_auth, доменное имя прокси и ваши адреса в ACL.

sudo tee /etc/squid/squid.conf > /dev/null <<'EOF'
 visible_hostname proxy.example.com
 
 auth_param basic program /usr/lib/squid/basic_ncsa_auth /etc/squid/passwd
 auth_param basic realm Private Squid Proxy
 auth_param basic credentialsttl 2 hours
 
 acl authenticated proxy_auth REQUIRED
 acl allowed_clients src 203.0.113.10/32 198.51.100.0/24
 
 acl SSL_ports port 443
 acl Safe_ports port 80
 acl Safe_ports port 443
 acl Safe_ports port 21
 acl Safe_ports port 70
 acl Safe_ports port 210
 acl Safe_ports port 1025-65535
 acl Safe_ports port 280
 acl Safe_ports port 488
 acl Safe_ports port 591
 acl Safe_ports port 777
 acl CONNECT method CONNECT
 
 http_port 3128
 
 http_access deny !Safe_ports
 http_access deny CONNECT !SSL_ports
 http_access allow allowed_clients authenticated
 http_access deny all
 
 cache deny all
 access_log stdio:/var/log/squid/access.log
 cache_log /var/log/squid/cache.log
 coredump_dir /var/spool/squid
 EOF

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

sudo squid -k parse
 sudo systemctl restart squid
 sudo systemctl status squid --no-pager
 ss -ltnp | grep squid

Если squid -k parse ругается на basic_ncsa_auth, почти всегда виноват неверный путь к helper. Если ругается на ACL, ищите опечатку в IP-сетях или в порядке правил.

Как открыть доступ только для своих IP и не подарить прокси всему интернету

Ограничение через ACL внутри Squid полезно, но лучше продублировать правило на firewall. Так вы срежете лишние подключения ещё до самого демона.

Ubuntu с UFW

sudo ufw allow from 203.0.113.10 to any port 3128 proto tcp
 sudo ufw allow from 198.51.100.0/24 to any port 3128 proto tcp
 sudo ufw reload

Rocky, AlmaLinux, RHEL с firewalld

sudo firewall-cmd --permanent --add-rich-rule='rule family="ipv4" source address="203.0.113.10/32" port protocol="tcp" port="3128" accept'
 sudo firewall-cmd --permanent --add-rich-rule='rule family="ipv4" source address="198.51.100.0/24" port protocol="tcp" port="3128" accept'
 sudo firewall-cmd --reload

Глобально открывать 3128/tcp на весь интернет не надо. Даже если пароль сложный, пользы от лишнего шума в логах ноль.

Проверка Squid через curl и разбор первых ошибок

Проверять браузером удобно, но curl честнее. Он сразу покажет, где проблема: в аутентификации, в ACL, в DNS или в самом порте.

curl -I -x http://proxy.example.com:3128 --proxy-user 'alice:СЛОЖНЫЙ_ПАРОЛЬ' https://example.com

Если всё нормально, увидите ответ сайта вроде HTTP/2 200 или 301. Если получаете 407 Proxy Authentication Required, проверьте пользователя, пароль и путь к helper. Если видите TCP_DENIED в логах Squid, чаще всего ваш IP не попал в allowed_clients.

Полезные команды для диагностики:

sudo tail -f /var/log/squid/access.log
 sudo tail -f /var/log/squid/cache.log
 sudo journalctl -u squid -e --no-pager

Как включить именно HTTPS-прокси в Squid через https_port

Теперь включим TLS на стороне самого прокси. Для нормальной работы нужен домен вроде proxy.example.com и сертификат. Если домена нет, можно использовать самоподписанный сертификат, но тогда клиентам придётся доверять вашему CA вручную. Для личного curl-клиента вариант терпимый. Для браузеров и разных устройств быстро становится неудобным.

Если домен есть, получите сертификат. Один из самых простых способов с certbot выглядит так:

sudo apt install certbot -y
 sudo certbot certonly --standalone -d proxy.example.com

Или на RHEL-подобных системах:

sudo dnf install certbot -y
 sudo certbot certonly --standalone -d proxy.example.com

После выпуска сертификата не спешите указывать в Squid файлы прямо из /etc/letsencrypt/live/.... Приватный ключ там обычно закрыт так, что пользователь Squid его не прочитает. Надёжнее скопировать сертификат и ключ в отдельный каталог, дать чтение только группе сервиса и работать уже с копиями.

sudo install -d -o root -g proxy -m 750 /etc/squid/certs
 sudo install -o root -g proxy -m 640 /etc/letsencrypt/live/proxy.example.com/fullchain.pem /etc/squid/certs/fullchain.pem
 sudo install -o root -g proxy -m 640 /etc/letsencrypt/live/proxy.example.com/privkey.pem /etc/squid/certs/privkey.pem

Теперь добавьте TLS-порт в конфиг. Обычный http_port 3128 можно оставить, а можно позже отключить, когда убедитесь, что ваши клиенты понимают HTTPS-прокси.

sudo tee -a /etc/squid/squid.conf > /dev/null <<'EOF'
 
 https_port 3129 tls-cert=/etc/squid/certs/fullchain.pem tls-key=/etc/squid/certs/privkey.pem options=NO_SSLv3,NO_TLSv1,NO_TLSv1_1
 EOF

Проверьте конфиг и перезапустите Squid:

sudo squid -k parse
 sudo systemctl restart squid
 ss -ltnp | grep 3129

Проверка через curl:

curl -I -x https://proxy.example.com:3129 --proxy-user 'alice:СЛОЖНЫЙ_ПАРОЛЬ' https://example.com

Если обычный порт 3128 работает, а 3129 нет, проблема почти всегда одна из трёх: пакет собран без TLS-поддержки, Squid не читает ключ, или ваш клиент плохо умеет HTTPS-прокси. В таком случае не пытайтесь «лечить» ситуацию включением ssl_bump. Проблема обычно не там.

Автообновление сертификата для HTTPS-прокси Squid

Самая частая поломка спустя два месяца выглядит так: прокси «вроде работает», но TLS-порт внезапно начинает ругаться на старый сертификат. Причина проста. Certbot обновил сертификат, а вы забыли переложить свежие файлы в каталог Squid и перезагрузить сервис.

Сделайте deploy-hook:

sudo tee /etc/letsencrypt/renewal-hooks/deploy/squid-cert.sh > /dev/null <<'EOF'
 #!/bin/sh
 install -d -o root -g proxy -m 750 /etc/squid/certs
 install -o root -g proxy -m 640 /etc/letsencrypt/live/proxy.example.com/fullchain.pem /etc/squid/certs/fullchain.pem
 install -o root -g proxy -m 640 /etc/letsencrypt/live/proxy.example.com/privkey.pem /etc/squid/certs/privkey.pem
 systemctl reload squid
 EOF
 sudo chmod +x /etc/letsencrypt/renewal-hooks/deploy/squid-cert.sh

Проверка без ожидания реального продления:

sudo certbot renew --dry-run

Типичные ошибки при настройке Squid на Linux

Когда Squid подходит, а когда лучше взять 3proxy или другой вариант

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

Но если задача узкая, например нужен маленький личный прокси без кэширования и без сложной логики, 3proxy бывает проще. Squid тяжелее, строже к конфигу и чаще наказывает за невнимательность. Взамен он даёт более зрелую политику доступа и предсказуемое поведение в корпоративных сценариях.

Ещё один важный момент касается безопасности. Squid регулярно получает исправления, и откладывать обновления не стоит. В 2025 году SecurityLab писал о критической уязвимости в Squid, так что схема «поставил и забыл» здесь плохая идея.

Практический вывод простой. Если вам нужен рабочий и безопасный прокси на Linux, сначала поднимите обычный Squid на 3128 с паролем и ограничением по IP. Проверьте доступ через curl, убедитесь, что логи чистые, и только потом добавляйте https_port. Такой порядок экономит часы отладки и резко снижает шанс превратить сервер в публичную прокси-помойку.

FAQ по установке HTTPS-прокси на Linux через Squid