Коротко — да, Squid может делать именно то, что вы хотите: по ACL перенаправлять запросы к конкретным доменам на локальные прокси, слушающие на разных портах. Но нужно учесть ряд практических нюансов в 2026‑м (и ещё раньше): поддержка сборок под Windows не так хороша, QUIC/HTTP3 (YouTube) и SOCKS‑родители требуют обходных решений. Резюме + как это настроить.
1) Подходит ли Squid на Windows сейчас?
- Технически — да, есть сборки Squid для Windows и способ запускать через нативные пакеты/портированные билды, но:
- официальная поддержка Windows у Squid всегда была вторичной; бинарные сборки часто делаются сообществом/третьими сторонами и могут отставать по версиям/фиксам;
- производительность/надёжность обычно лучше на Linux (меньше проблем с правами, сетевыми стеком, сервисами);
- удобнее и безопаснее запускать Squid на Linux (VM, контейнер, WSL2) на той же машине Windows, чем нативную Windows‑сборку.
- Вывод: если нужен стабильный долгосрочный прокси с гибкостью — рекомендую ставить Squid в Linux (VM/WSL2/docker). Но для одноразовой/тестовой задачи можно и Windows‑сборку.
2) Можно ли по ACL направлять запросы к разным локальным прокси?
Да. Механизм: cache_peer + cache_peer_access + never_direct/always_direct. ACL можно задавать dstdomain/dst (для HTTP Host и CONNECT), и для HTTPS CONNECT вы сможете ориентироваться по хосту в CONNECT (браузер посылает host:port), а при перехвате/ssl_bump можно смотреть SNI.
Примеры и пояснения:
- Предположим, у вас:
- Shadowsocks локально как SOCKS5 на 127.0.0.1:1080
- Privoxy (или другой http→socks форвардер) на 127.0.0.1:8118 (перенаправляет в SOCKS5)
- noDPI‑прокси (HTTP) на 127.0.0.1:3129
Squid сам не умеет напрямую быть клиентом SOCKS5, поэтому для Shadowsocks обычно ставят HTTP‑форвардер (privoxy/redsocks/3proxy) и пускают Squid к нему как к HTTP‑родителю.
Простой конфиг‑фрагмент (схематично):
# локальный порт Squid
http_port 3128
# определяем "родителей"
cache_peer 127.0.0.1 parent 8118 0 no-query name=privoxy
cache_peer 127.0.0.1 parent 3129 0 no-query name=nodpi
# ACLы по доменам
acl YOUTUBE dstdomain .youtube.com .googlevideo.com .ytimg.com
acl BLOCKED dstdomain .blocked.example
# позволяем определённым peer'ам обслуживать нужные ACLы
cache_peer_access privoxy allow YOUTUBE
cache_peer_access privoxy deny all
cache_peer_access nodpi allow BLOCKED
cache_peer_access nodpi deny all
# не давать Squid идти напрямую для этих ACL (чтобы точно шло через peer)
never_direct allow YOUTUBE
never_direct allow BLOCKED
# по умолчанию — прямой доступ (или настроите другой parent)
always_direct allow all
Пояснения:
- cache_peer_access <имя> allow <acl> — разрешает использовать данного parent для трафика, попадающего под ACL.
- always_direct/never_direct контролируют, может ли Squid идти напрямую к хосту — если хотите гарантировать использование parent, запретите direct (never_direct).
- Для HTTPS CONNECT dstdomain и dst работают (браузер передаёт host:port в CONNECT). Если хотите более тонко по SNI — нужен ssl_bump/peek с соответствующими acl (это сложнее, требует MITM сертификатов).
3) Ограничения и подводные камни
- SOCKS: Squid не умеет быть клиентом SOCKS5 «из коробки». Используйте HTTP→SOCKS форвардер (Privoxy, redsocks, 3proxy) на localhost и указывайте этот HTTP‑форвардер как cache_peer.
- QUIC/HTTP3 (YouTube и др.): эти протоколы используют UDP (QUIC). HTTP‑прокси (и Squid) работают по TCP, поэтому часть трафика (HTTP/3) не будет проксироваться через Squid. Возможные решения:
- Отключить QUIC/HTTP3 в браузере (например, chrome://flags), тогда видеопоток пойдёт по TCP и Squid/фиксы сработают.
- Использовать туннелирование на уровне сокса/правил (tun2socks, WinDivert + shadowsocks/redsocks), которые умеют перехватывать UDP.
- HTTP/2/HTTP/3: Squid может быть ограничен по поддержке новейших фич, иногда возникают несовместимости.
- HTTPS и приватность: если хотите «глубже» смотреть SNI/заголовки и делать правила по ним, придётся использовать ssl_bump (interception), что влечёт за собой установку CA‑сертификата на клиента и юридические/безопасностные риски.
- Поддержка/обновления: на Windows, при возникновении багов, найти исправления и собрать свежую версию может быть сложнее, чем на Linux.
4) Практические рекомендации
- Для надёжности и простоты разворачивайте Squid в Linux (VM/WSL2/docker) даже если конечная система — Windows.
- Для chaining Shadowsocks используйте Privoxy или 3proxy для превращения SOCKS в HTTP.
- Для YouTube учитывайте QUIC/HTTP3 — возможно проще настроить браузер использовать локальный SOCKS/Proxy для этих доменов (Proxifier, SwitchyOmega + системный socks), либо тупо отключать QUIC.
- Тестируйте логи Squid (access.log) и используйте tcpdump/wireshark, чтобы понять, как идут соединения.
- Если нужна простая per‑app или per‑domain маршрутизация на Windows без Squid — посмотрите Proxifier, SimpleWall+WinDivert/tun2socks, 3proxy (Windows билд) — иногда они проще для чистого цепления SOCKS/HTTP и UDP.
Итог
- Да, Squid умеет на уровне ACL перенаправлять запросы на разные локальные HTTP‑родители (cache_peer + cache_peer_access + never_direct), и это рабочее решение для HTTP/CONNECT.
- На Windows в 2026 лучше запускать Squid в Linux (VM/WSL/docker) из соображений надёжности и поддержки; для SOCKS/QUIC потребуется дополнительные прокси‑прослойки (privoxy/redsocks/tun2socks и т.п.).
Если хотите, могу:
- Составить минимальный рабочий squid.conf под вашу конкретную схему (какие порты, какие локальные прокси),
- Показать, как настроить privoxy для переадресации в shadowsocks,
- Посоветовать, как обработать QUIC/HTTP3 для YouTube.