Rocky Linux 8 下部署 Squid 正向代理实战指南

1. 项目概述：为什么在 Rocky Linux 8 上亲手搭一个 Squid 代理不是“多此一举”

Squid、Proxy、Rocky Linux 8——这三个词凑在一起，不是在讲某个云服务控制台里点几下就能开通的“一键代理”，而是一次对系统底层网络控制权的真实拿回。我见过太多人卡在“cc switch local proxy failed while handling”这类报错上，翻遍日志只看到一串 status 401/403/502，却不知道这些状态码背后，根本不是应用本身的问题，而是代理链路在操作系统层就断了、歪了、或者压根没被正确识别。比如 http proxy: http.docker.internal:3128 禁用不了 ，问题不在 Docker，而在宿主机的代理策略没穿透进容器网络命名空间；再比如 valueerror: unknown scheme for proxy url url('socks://127.0.0.1:7892/') ，错误提示指向 Python 库不支持 socks 协议，但真正该问的是：你为什么非得让业务程序自己处理 socks？为什么不把 socks 转成标准 HTTP/HTTPS 代理，让所有工具（curl、git、yum、pip、Java JVM）零改造接入？这就是 Squid 的核心价值：它不制造协议，它统一协议；它不替代工具，它赋能工具。

Rocky Linux 8 是 CentOS 生态最主流的继任者，内核 4.18、默认使用 firewalld + NetworkManager + systemd-resolved，这套组合和旧版 CentOS 7 差异不小。很多网上抄来的 Squid 配置，在 Rocky Linux 8 上跑不起来，不是因为 Squid 本身变了，而是 SELinux 策略更严、firewalld zone 默认不放行 3128 端口、systemd-resolved 把 /etc/resolv.conf 指向 127.0.0.53 导致 Squid DNS 解析失败——这些细节，文档不会写，但实操中每一条都足以让你卡住两小时。所以这个项目不是教你怎么敲 dnf install squid ，而是带你从 Rocky Linux 8 的系统肌理出发，把 Squid 嵌进它的血管里：让防火墙认它、让 DNS 信它、让 SELinux 放行它、让所有命令行工具自然地用上它。适合三类人：需要稳定复现开发环境的后端工程师、要批量管理服务器的运维同学、以及正在被各种 “unexpected status XXX” 报错折磨的 DevOps 新手。你不需要懂 HTTP 协议栈，但得愿意关掉图形界面，打开终端，一行一行确认配置是否真正生效。

2. 整体设计思路：为什么选 Squid 而不是 Nginx 或 Caddy 做正向代理

2.1 Squid 的不可替代性：专为缓存与访问控制而生

很多人第一反应是：“Nginx 不也能做代理？”——能，但它是“通用型选手”，而 Squid 是“特种兵”。Nginx 的 proxy_pass 模块本质是请求转发器，它不解析 HTTP 请求头里的 Cache-Control、ETag、Vary 字段，不做对象级缓存淘汰，也不内置用户认证网关。而 Squid 从诞生第一天起，就是为解决“如何让上千台客户端高效、安全、可控地共享一个出口带宽”而设计的。它原生支持：

• 分层缓存策略 ：可配置 refresh_pattern 精确控制不同 MIME 类型（如 .deb 包、.rpm 包、JSON API 响应）的缓存时长，避免 unknown host 'central.maven.org' 这类因 DNS 缓存过期导致的构建失败；
• 细粒度 ACL 控制 ：不仅能按 IP 段放行，还能按 URL 正则、HTTP 方法（GET/POST）、时间窗口（工作日 9–18 点）、甚至客户端证书 DN 字段做策略，这是应对 unexpected status 403 forbidden 最底层的防御手段；
• 透明代理能力 ：配合 iptables TPROXY，可实现“客户端无感知”的强制代理，彻底规避 git set proxy 或 export https_proxy 配置遗漏问题；
• 完整的日志审计体系 ：access.log 记录完整请求时间、客户端 IP、目标域名、响应状态码、字节数、缓存命中状态（TCP_HIT/TCP_MISS），这是排查 cc switch local proxy failed while handling codex endpoint /responses 类问题的唯一证据链。

提示：如果你只是想临时转发一个端口（比如把本地 8080 映射到公网），用 Nginx 完全没问题；但如果你要支撑团队共用、需要审计、要防滥用、要加速重复请求，Squid 是经过三十年生产环境验证的唯一选择。

2.2 为什么必须基于 Rocky Linux 8 原生仓库安装，而非源码编译

Rocky Linux 8 的 dnf 仓库中 Squid 版本是 4.11（截至 2024 年中），它已预编译并适配了系统级组件：

• SELinux 策略已内置 ： semanage fcontext -l | grep squid 可查到 /var/spool/squid(/.*)? 默认标记为 squid_cache_t ，若自行编译安装到 /opt/squid ，SELinux 会直接拒绝其读写缓存目录，报错 Permission denied ，而你可能花半天才意识到是 SELinux 在拦路；
• systemd 服务单元文件开箱即用 ： /usr/lib/systemd/system/squid.service 已定义 Type=forking 、 PIDFile=/var/run/squid.pid 、 LimitNOFILE=65536 ，还包含 ExecStartPre=/usr/libexec/squid/cache_swap.sh 自动初始化缓存目录，省去手动 squid -z 的步骤；
• firewalld service 文件已注册 ： /usr/lib/firewalld/services/squid.xml 定义了 3128/tcp 端口，执行 firewall-cmd --add-service=squid 即可生效，无需记忆端口号。

我试过源码编译 Squid 5.9，功能确实更新（支持 HTTP/3），但在 Rocky Linux 8 上遇到两个硬伤：一是 --enable-ssl-crtd 编译选项依赖 OpenSSL 3.0+，而系统默认是 1.1.1k，强行升级会破坏 yum；二是生成的 systemd 服务文件缺少 RestartSec=5 ，导致进程崩溃后无法自动拉起，这在生产环境是致命缺陷。所以结论很明确：用 dnf install squid ，不是偷懒，是尊重操作系统的设计契约。

2.3 架构设计：三层隔离模型保障稳定性与可维护性

我们不追求“一台机器干所有事”，而是按职责切分：

这个设计直接解决了 unexpected status 502 bad gateway 的常见诱因：不是 Squid 本身崩了，而是它上游的父代理（比如公司统一出口网关）挂了，Squid 却没有配置 fallback 机制，所有请求直接返回 502。通过 cache_peer 定义多个上游，并设置 weight 和 proxy-only ，就能让 Squid 自动在可用节点间切换。

3. 核心细节解析：Rocky Linux 8 特有陷阱与绕过方案

3.1 SELinux：那个总在后台默默搞破坏的“安全卫士”

Rocky Linux 8 默认启用 enforcing 模式，Squid 的几个关键路径受严格管控：

• /var/spool/squid ：必须是 squid_cache_t 类型，否则 squid -z 初始化失败；
• /etc/squid/squid.conf ：必须是 squid_conf_t 类型，否则 systemctl start squid 报错 Cannot open configuration file ；
• /var/log/squid/access.log ：必须是 squid_log_t 类型，否则日志写入失败， tail -f /var/log/squid/access.log 一直空。

验证方法：

ls -Z /var/spool/squid
# 正确输出：system_u:object_r:squid_cache_t:s0 /var/spool/squid
ls -Z /etc/squid/squid.conf
# 正确输出：system_u:object_r:squid_conf_t:s0 /etc/squid/squid.conf

如果类型错误，不要 setenforce 0 （这是自欺欺人），而应重置上下文：

sudo semanage fcontext -a -t squid_cache_t "/var/spool/squid(/.*)?"
sudo semanage fcontext -a -t squid_conf_t "/etc/squid/squid.conf"
sudo restorecon -Rv /var/spool/squid /etc/squid/squid.conf

注意： semanage 命令需先安装 policycoreutils-python-utils 包， dnf install policycoreutils-python-utils -y 。这是 Rocky Linux 8 和 CentOS 7 的一个关键差异——CentOS 7 的 semanage 在 policycoreutils-python 包里，而 Rocky Linux 8 拆到了新包。

3.2 DNS 解析：systemd-resolved 的“隐形拦截”

Rocky Linux 8 默认启用 systemd-resolved ，它把 /etc/resolv.conf 符号链接到 /run/systemd/resolve/stub-resolv.conf ，内容是 nameserver 127.0.0.53 。问题来了：Squid 进程启动时，会读取 /etc/resolv.conf 获取 DNS 服务器，但 127.0.0.53 是 systemd-resolved 的 stub listener，它只响应本机查询，不转发给上游 DNS。结果就是 Squid 启动时报 FATAL: Failed to initialize DNS ，或者运行中大量 DNS Timeout ，导致 unknown host 'central.maven.org' 。

解决方案有二，推荐后者：

方案一（治标）：让 Squid 直连真实 DNS

echo "dns_nameservers 8.8.8.8 114.114.114.114" >> /etc/squid/squid.conf

但这绕过了 systemd-resolved 的 DNSSEC 验证和缓存，且不符合企业内网规范。

方案二（治本）：配置 Squid 使用 systemd-resolved 的真实 upstream

# 查看 systemd-resolved 的真实 upstream
resolvectl status | grep "DNS Servers"
# 输出类似：DNS Servers: 192.168.1.1 2001:db8::1

# 在 squid.conf 中指定
dns_nameservers 192.168.1.1

这样既保持了内网 DNS 策略，又避免了 stub listener 的限制。

3.3 FirewallD：别让 3128 端口死在防火墙门口

Rocky Linux 8 默认 firewalld zone 是 public ，它默认 不放行 3128 端口 。即使 Squid 进程正常运行、 netstat -tlnp | grep :3128 显示监听，外部客户端依然连接超时。这不是 Squid 的错，是防火墙在拦截。

验证方法：

sudo firewall-cmd --list-all | grep ports
# 如果没输出 3128/tcp，说明端口未开放

正确操作不是 --add-port=3128/tcp （临时规则，重启失效），而是启用预定义的 squid service：

sudo firewall-cmd --permanent --add-service=squid
sudo firewall-cmd --reload

--permanent 参数确保规则写入 /etc/firewalld/zones/public.xml ，永久生效。这是 Rocky Linux 8 的最佳实践——用 service 抽象端口，而不是裸写端口号，便于后续审计和迁移。

3.4 缓存目录初始化：XFS 文件系统的隐藏要求

Squid 缓存目录 /var/spool/squid 必须是 XFS 或 ext4 文件系统，但 Rocky Linux 8 安装时默认格式化为 XFS。XFS 对 Squid 有个硬性要求： 必须启用 inode64 挂载选项 ，否则当缓存对象超过 100 万个时，Squid 会报错 ERROR: Could not create swap log ，因为默认 XFS 使用 32 位 inode，寻址空间不足。

检查方法：

mount | grep " /var/spool/squid "
# 正确输出应含：inode64
# 错误输出：rw,relatime,attr2,inode64,logbufs=8,logbsize=32k,noquota

如果没 inode64 ，需重新挂载（假设 /var/spool/squid 是独立分区）：

# 先卸载（确保 squid 已停止）
sudo systemctl stop squid
sudo umount /var/spool/squid

# 重新挂载并写入 fstab
echo "/dev/sdb1 /var/spool/squid xfs defaults,inode64 0 0" >> /etc/fstab
sudo mount -a

实操心得：我曾在一个客户环境踩过这个坑。他们用 LVM 创建了 /var/spool/squid 逻辑卷，但创建时没加 -i size=512 参数，导致 XFS 默认用 256 字节 inode，撑不过 50 万文件就崩。后来用 xfs_info /var/spool/squid 查 inode size，确认是 256，才定位到根源。

4. 实操全流程：从安装到生产就绪的 7 个关键步骤

4.1 步骤一：基础安装与服务准备（3 分钟）

# 更新系统（关键！避免 kernel 与 squid 内核模块不兼容）
sudo dnf update -y

# 安装 Squid 及必要工具
sudo dnf install -y squid net-tools bind-utils policycoreutils-python-utils

# 启用并启动服务（此时会失败，因为配置未调好，属正常）
sudo systemctl enable squid
sudo systemctl start squid
sudo systemctl status squid
# 预期看到：Active: failed (Result: exit-code)

为什么第一次启动必败？因为默认 /etc/squid/squid.conf 是为透明代理设计的， http_port 监听在 3128 但 acl localnet src 规则只放行 127.0.0.1/32 ，外部客户端连不上。这不是 bug，是安全默认值。

4.2 步骤二：最小化安全配置（10 分钟）

编辑 /etc/squid/squid.conf ， 删除全部内容，粘贴以下最小可行配置 （逐行解释）：

# 1. 监听地址与端口 —— 绑定到所有接口，但仅允许内网访问
http_port 3128
# 注：不加 intercept，不做透明代理，避免复杂路由配置

# 2. 定义可访问的客户端网段（根据你的实际网络修改！）
acl localnet src 192.168.1.0/24    # 公司内网
acl localnet src 10.0.0.0/8       # 私有云 VPC
acl localnet src 127.0.0.1/32     # 本机测试

# 3. 定义管理接口（仅限本机）
acl manager proto cache_object
acl localhost src 127.0.0.1/32
http_access allow manager localhost
http_access deny manager

# 4. 核心访问控制：只允许 localnet 访问，拒绝其他所有
http_access allow localnet
http_access deny all

# 5. 缓存策略：对静态资源缓存 1 天，API 响应不缓存
refresh_pattern -i \.(jpg|jpeg|png|gif|css|js)$ 1440 20% 10080
refresh_pattern -i \.(deb|rpm|tar|gz|zip)$ 10080 90% 43200
refresh_pattern . 0 0% 1

# 6. 日志与性能
access_log /var/log/squid/access.log squid
cache_log /var/log/squid/cache.log
cache_store_log /var/log/squid/store.log
cache_mem 256 MB
maximum_object_size 1024 MB

关键参数说明：

• refresh_pattern . 0 0% 1 ： . 匹配所有 URL， 0 表示最小刷新时间（秒）， 0% 表示忽略原始响应的 Cache-Control: max-age ， 1 表示最大刷新时间（秒）。这行确保所有动态请求（如 /api/v1/users ）绝不缓存，避免 cc switch local proxy failed while handling 类问题因陈旧响应导致。
• cache_mem 256 MB ：Squid 内存缓存大小，设为物理内存的 1/4（假设 1GB RAM），避免 OOM Killer 杀进程。

4.3 步骤三：SELinux 上下文修复（2 分钟）

# 重置 squid 目录安全上下文
sudo semanage fcontext -a -t squid_cache_t "/var/spool/squid(/.*)?"
sudo semanage fcontext -a -t squid_conf_t "/etc/squid/squid.conf"
sudo semanage fcontext -a -t squid_log_t "/var/log/squid(/.*)?"

# 应用变更
sudo restorecon -Rv /var/spool/squid /etc/squid/squid.conf /var/log/squid

# 验证
ls -Z /var/spool/squid | head -1
# 应输出：system_u:object_r:squid_cache_t:s0

4.4 步骤四：DNS 与防火墙配置（3 分钟）

# 设置 DNS（替换为你内网 DNS 服务器）
echo "dns_nameservers 192.168.1.1" >> /etc/squid/squid.conf

# 开放防火墙
sudo firewall-cmd --permanent --add-service=squid
sudo firewall-cmd --reload

# 验证端口开放
sudo ss -tlnp | grep :3128
# 应输出：LISTEN 0 128 *:3128 *:* users:(("squid",pid=1234,fd=10))

4.5 步骤五：初始化缓存并启动（5 分钟）

# 初始化缓存目录（自动创建子目录、设置权限）
sudo squid -z

# 检查初始化日志
sudo tail -20 /var/log/squid/cache.log
# 应看到：Ready to serve requests.

# 启动服务
sudo systemctl start squid
sudo systemctl status squid
# 预期：Active: active (running)

# 检查监听状态
sudo ss -tlnp | grep squid
# 应显示：0.0.0.0:3128 或 [::]:3128

注意： squid -z 必须由 root 执行，且 /var/spool/squid 所有者必须是 squid:squid 。如果报错 FATAL: Cannot open '/var/spool/squid/00/00': (13) Permission denied ，执行 sudo chown -R squid:squid /var/spool/squid 。

4.6 步骤六：客户端验证与调试（15 分钟）

本地 curl 测试（最可靠）：

# 不走代理（基准线）
curl -I http://example.com | head -1
# 应输出：HTTP/1.1 200 OK

# 走代理（关键验证）
curl -x http://127.0.0.1:3128 -I http://example.com | head -1
# 应输出：HTTP/1.1 200 OK

# 查看 access.log 实时记录
sudo tail -f /var/log/squid/access.log
# 发送请求后，应看到类似：
# 1712345678.123 123 127.0.0.1 TCP_MISS/200 12345 GET http://example.com/ - HIER_DIRECT/93.184.216.34 text/html
# 其中 TCP_MISS 表示未命中缓存，TCP_HIT 表示命中

Git 验证（典型场景）：

# 设置 Git 代理
git config --global http.proxy http://127.0.0.1:3128
git config --global https.proxy http://127.0.0.1:3128

# 测试克隆（应成功，且 access.log 有记录）
git clone https://github.com/torvalds/linux.git /tmp/test-linux

# 取消代理（避免影响其他操作）
git config --global --unset http.proxy
git config --global --unset https.proxy

排查 unexpected status 401 unauthorized ： 此错误通常因目标网站（如私有 GitLab）要求 Basic Auth，但 Squid 未配置 auth_param 。临时解决是让 Squid 透传认证头：

# 在 squid.conf 中添加
follow_x_forwarded_for allow all
# 并重启 squid
sudo systemctl restart squid

长期方案是配置 Squid 的 Basic 认证网关，但这超出本项目范围。

4.7 步骤七：生产加固（10 分钟）

完成基础功能后，必须做三件事才能上生产：

1. 启用访问日志轮转（防止磁盘打满）

# 编辑 logrotate 配置
sudo tee /etc/logrotate.d/squid << 'EOF'
/var/log/squid/*.log {
    daily
    missingok
    rotate 52
    compress
    delaycompress
    notifempty
    create 644 squid squid
    sharedscripts
    postrotate
        /usr/sbin/squid -k rotate > /dev/null 2>&1 || true
    endscript
}
EOF

2. 配置监控（用 systemd-journal 替代复杂 Prometheus）

# 查看最近 1 小时 Squid 错误
sudo journalctl -u squid --since "1 hour ago" | grep -i "error\|fail\|denied"

# 设置邮件告警（示例：当出现 502 错误时发邮件）
# 需先配置 mailx，此处略

3. 性能调优（针对高并发）

# 在 squid.conf 末尾添加
# 提升并发连接数
max_filedescriptors 65536

# 减少 TIME_WAIT 占用
tcp_keepalive on
tcp_fin_wait2_timeout 30

# 异步 I/O 加速缓存读写
store_dir_select_algorithm round-robin

然后调整系统参数：

echo "net.core.somaxconn = 65535" >> /etc/sysctl.conf
echo "net.ipv4.tcp_fin_timeout = 30" >> /etc/sysctl.conf
sudo sysctl -p

5. 常见问题与排查技巧实录：那些让我熬夜到凌晨的报错

5.1 FATAL: Failed to initialize DNS —— DNS 解析失败的 3 种根因

实操心得：有一次客户环境， resolvectl status 显示 DNS 是 10.10.10.10 ，但 Squid 还是解析失败。最后发现是 10.10.10.10 这台 DNS 服务器本身被防火墙策略禁止响应来自 192.168.1.100 （Squid 服务器）的查询。用 tcpdump -i any port 53 抓包，看到 DNS 请求发出但无响应，才定位到上游防火墙问题。

5.2 TCP_DENIED/403 —— 访问被拒的 ACL 逻辑陷阱

access.log 中出现 TCP_DENIED/403 ，表示 Squid 明确拒绝了请求。常见原因：

• ACL 顺序错误 ：Squid 按 http_access 顺序匹配，第一个匹配的规则生效。错误配置：

  http_access deny all      # 第1行
  http_access allow localnet # 第2行 → 永远不执行！
  

  正确顺序必须是 allow 在前， deny all 在最后。

• IP 段写错 ： acl localnet src 192.168.0.0/16 写成 192.168.0.0/24 ，导致 192.168.1.100 客户端被拒。

• IPv6 地址未覆盖 ：客户端用 IPv6 访问，但 acl localnet src 只写了 IPv4。应补充：

  acl localnet src fc00::/7   # ULAs
  acl localnet src fe80::/10  # Link-local
  

验证 ACL 是否生效：

# 模拟客户端请求，查看匹配的 ACL 名
sudo squid -k parse
sudo squid -d 1 -N | grep "ACL.*matched"
# 启动 Squid 调试模式，实时打印 ACL 匹配过程

5.3 TCP_MISS/502 —— 上游网关故障的快速切换

502 Bad Gateway 表示 Squid 连接上游失败。不是 Squid 的错，但你可以让它更聪明：

方案：配置 cache_peer 实现双活上游

# 主上游：公司出口网关
cache_peer 192.168.10.1 parent 3128 0 no-query default weight=10

# 备上游：公共 DNS+直连（当主挂时自动切换）
cache_peer 8.8.8.8 parent 80 0 no-query no-digest weight=1

# 启用健康检查
peer_health_check_interval 10 seconds

这样当 192.168.10.1 不可用时，Squid 会在 10 秒内探测到，并将流量切到 8.8.8.8 ，避免全站 502 。

5.4 TCP_REFRESH_UNMODIFIED/304 —— 缓存策略导致的“假失败”

有时客户端收到 304 Not Modified ，误以为请求失败。其实这是 Squid 的正常行为：客户端发送 If-None-Match ，Squid 发现缓存未过期，直接返回 304 ，不走上游。这能节省 90% 带宽，但某些老旧脚本会把 304 当错误处理。

解决：在 squid.conf 中禁用协商缓存（不推荐，仅调试用）：

# 强制所有响应为 200，禁用 304
refresh_pattern . 0 0% 0 ignore-no-cache ignore-reload

5.5 ERR_CONNECT_FAIL —— 客户端连接超时的 5 层排查法

当 curl -x http://ip:3128 http://example.com 超时，按 OSI 模型逐层排查：

我踩过的最大坑：某次 nc -zv 成功，但 curl 超时。最后发现是 Rocky Linux 8 的 NetworkManager 启用了 ipv6 ，而 Squid 配置中 http_port 只监听 IPv4（ 0.0.0.0:3128 ），但客户端优先走 IPv6，导致连接被丢弃。解决方案是在 squid.conf 中显式声明：

http_port 0.0.0.0:3128
http_port [::]:3128

6. 进阶扩展：从单机代理到企业级网关的 3 条演进路径

6.1 路径一：集成 LDAP 认证，实现账号级访问控制

当团队超过 20 人，IP 白名单不再够用。Squid 原生支持 basic_ncsa_auth （文件认证）和 basic_ldap_auth （LDAP 认证）。以 OpenLDAP 为例：

# 安装 LDAP 认证模块
sudo dnf install -y squid-ldap-auth

# 配置 squid.conf
auth_param basic program /usr/lib64/squid/basic_ldap_auth -R -b "dc=example,dc=com" -D "cn=admin,dc=example,dc=com" -W /etc/squid/ldap.pass -f "uid=%s" -h ldap.example.com
auth_param basic children 5
auth_param basic realm Squid Proxy Authentication
auth_param basic credentialsttl 2 hours

# ACL 规则
acl authenticated_users proxy_auth REQUIRED
http_access allow authenticated_users
http_access deny all

/etc/squid/ldap.pass 存放 LDAP 管理员密码，权限 600 。这样每个用户用域账号密码登录， access.log 会记录 username 字段，审计更精准。

6.2 路径二：部署 SquidGuard，实现 URL 黑白名单过滤

对付 unexpected status 403 forbidden 的终极方案：不让恶意请求发出。SquidGuard 是 Squid 的经典插件，支持：

• URL 黑名单 ：阻止访问 malware-site.com ；
• 广告过滤 ：屏蔽 doubleclick.net ；
• 时间策略 ：工作日 12:00–13:00 禁止访问社交媒体。

安装：

sudo dnf install -y squidguard
sudo squidGuard -C -c /etc/squidguard/squidGuard.conf

配置 /etc/squidguard/squidGuard.conf 后，Squid 配置中加入：

url_rewrite_program /usr/bin/squidGuard -c /etc/squidguard/squidGuard.conf

6.3 路径三：构建 Squid 集群，实现高可用与负载均衡

单台 Squid 有性能瓶颈（约 5000 并发连接）。用 cache_peer 可构建层次结构：

• 边缘节点（Edge） ：部署在各办公区，负责本地缓存；
• 中心节点（Parent） ：部署在数据中心，聚合所有边缘请求，直连互联网；
• 备份节点（Sibling） ：