23、Squid反向代理模式的全面配置与应用

原创于 2025-07-25 10:41:00 发布 · 201 阅读

0 ·

CC 4.0 BY-SA版权

文章标签：

#Squid # 反向代理 # HTTPS配置

掌握Squid 3.1：优化网络性能的秘籍专栏收录该内容

25 篇文章 ¥499.90

订阅专栏¥69.90

会员秒杀 ¥9.9 重磅福利

超级会员免费看

Squid反向代理模式的全面配置与应用

1. HTTPS选项配置

在反向代理模式下，Squid的 https_port 指令有特定的语法，其基本格式如下：

https_port [IP_ADDRESS:]port accel cert=certificate.pem [key=key.pem] [options]

IP_ADDRESS ：可选参数，指定Squid绑定的IP地址。
port ：指定Squid监听HTTPS请求的端口。
cert ：指定SSL证书文件或OpenSSL兼容的组合证书和私钥文件的绝对路径。
key ：可选参数，指定SSL私钥文件的绝对路径。若未指定，Squid将认为 cert 参数指定的文件为组合证书和私钥文件。

1.1 其他选项说明

选项	说明
`defaultsite`	指定在HTTP Host头缺失时使用的默认HTTPS网站，格式为 `defaultsite=domain_name` 。
`vhost`	支持虚拟托管域名，使用该选项时，指定的证书应为通配符证书或对多个域名有效的证书。
`version`	指定要支持的SSL/TLS协议版本，可能的值如下： 1 - 自动检测（默认值）； 2 - 仅支持SSLv2； 3 - 仅支持SSLv3； 4 - 仅支持TLSv1。
`cipher`	使用冒号分隔的列表指定支持的密码套件，如 `cipher=COLON_SEPARATED_LIST` 。需检查OpenSSL版本对密码套件的支持情况。
`options`	以冒号分隔的列表形式指定各种SSL引擎特定选项，如 `options=LIST` 。需检查OpenSSL版本对这些选项的支持情况。
`clientca`	指定包含证书颁发机构（CAs）列表的文件的绝对路径，用于请求客户端证书。
`cafile`	指定包含额外CA证书的文件，用于验证客户端证书。
`capath`	指定包含额外证书和CRL（证书吊销列表）的目录的绝对路径，用于验证客户端证书。
`crlfile`	指定包含额外CRL列表的文件的绝对路径，用于验证客户端证书。
`dhparams`	指定包含DH密钥交换参数的文件，用于DH密钥交换。
`sslflags`	指定一个或多个标志来修改SSL的使用，可用标志如下： `NO_DEFAULT_CA` - 不使用OpenSSL内置的默认CA列表； `NO_SESSION_REUSE` - 每个新连接都是新的SSL连接，不重用连接； `VERIFY_CRL` - 在接受客户端证书之前，使用 `crlfile` 或 `capath` 选项指定的文件中的CRL列表验证客户端证书； `VERIFY_CRL_ALL` - 验证客户端证书链中的所有证书。
`sslcontext`	设置SSL会话ID上下文标识符。
`vport`	启用基于IP的虚拟主机支持，用法与 `http_port` 指令中的 `vport` 选项相同。

1.2 示例

https_port 443 accel defaultsite=secure.example.com cert=/opt/squid/etc/squid_combined.pem sslflags=NO_DEFAULT_CA
https_port 443 accel vhost cert=/opt/squid/etc/squid.pem key=/opt/squid/etc/squid_key.pem

2. 添加后端Web服务器

Squid接收HTTP或HTTPS请求后，需要将其转发到Web服务器以获取内容，然后将内容返回给请求的客户端。可以使用Squid配置中的 cache_peer 指令添加一个或多个Web服务器。

2.1 反向代理模式下的缓存对等选项

选项	说明
`originserver`	将缓存对等体视为源Web服务器。
`forcedomain`	配置Squid始终发送指定域名的主机头，通常用于修复在多个域名下公开可用的损坏源服务器。若源服务器能够处理多个域名，则应避免使用此选项。

2.2 示例

cache_peer 127.0.0.1 parent 80 0 no-query no-digest originserver
cache_peer local_ip_of_web_server parent 80 no-query originserver forcedomain=www.example.com

3. 代理协议支持

3.1 代理协议工作原理

请求和响应可能会通过一系列服务器代理（反向代理或源服务器加速器）和正向缓存代理。服务器代理代表源服务器行事，具有与源服务器相同的权限。代理协议扩展了HTTP协议，为服务器代理分配不同的控制，这些控制可以与分配给中间正向代理或HTTP客户端的控制不同。

当代理接收到请求时，会构建类似以下的请求：

GET / HTTP/1.1
...
Surrogate-Capability: mirror.example.com="Surrogate/1.0"
...

源Web服务器接收到请求后，会构建包含适当代理控制HTTP头的响应，例如：

HTTP/1.1 200OK
...
Cache-Control: no-cache, max-age=1800, s-max-age=3600
Surrogate-Control: max-age=43200;mirror.example.com
...

3.2 控制说明

角色	缓存时间
HTTP客户端	最多半小时（由 `Cache-Control: max-age=1800` 决定）。
正向代理	最多一小时（由 `Cache-Control: s-max-age=3600` 决定）。
代理（标识为 `mirror.example.com` ）	最多半天（由 `Surrogate-Control: max-age=43200` 决定）。

3.3 代理支持的配置选项

指令	说明
`httpd_accel_surrogate_id`	设置代理ID，默认值与 `visible_hostname` 相同。示例： `httpd_accel_surrogate_id mirror1.example.com` 。
`httpd_accel_surrogate_remote`	将代理服务器宣传为远程代理，仅当代理服务器距离源服务器两跳或更多跳时才应设置为 `on` 。示例： `http_accel_surrogate_remote on` 。

4. ESI协议支持

ESI（Edge Side Includes）是一种基于XML的标记语言，可在互联网边缘或靠近最终用户的位置动态组装HTML内容。

4.1 ESI协议的优点

允许代理缓存部分Web文档，提高命中率。
减少源服务器的处理开销，因为资源组装可以由代理或HTTP客户端本身执行。
增强内容的可用性。
提高最终用户的性能，因为可以从多个缓存中获取内容。

4.2 配置Squid支持ESI

4.2.1 编译Squid时启用ESI支持

使用 --enable-esi 选项配置编译程序：

./configure --enable-esi

4.2.2 选择ESI标记的解析器

在Squid配置文件中使用 esi_parser 指令，示例：

esi_parser libxml2

可选择的解析器有 libxml2 、 expat 或 custom ，默认解析器为 custom 。需要注意的是，ESI标记并非严格的XML兼容，自定义ESI解析器性能较高，但无法处理非ASCII字符编码，可能导致意外行为。

5. 日志记录

5.1 以Web服务器日志格式记录消息

在反向代理模式下，Squid的缓存可以满足的请求不会到达Web服务器，导致大部分Web服务器日志消息丢失。可以使用 access_log 指令的通用日志格式，使Squid以Apache Web服务器日志格式记录消息。

5.2 忽略浏览器重新加载

大多数浏览器的重新加载按钮会将 Cache-Control HTTP头设置为 no-cache ，这会导致Squid清除缓存内容并从源服务器重新获取，即使缓存内容仍然有效，从而造成资源浪费。可以使用以下三种方法解决此问题：

5.2.1 使用 `ignore-cc`

在指定HTTP端口时使用 ignore-cc 选项，Squid将忽略客户端的 Cache-Control HTTP头，完全依赖后端Web服务器提供的 Cache-Control 头。示例：

http_port 80 accel defaultsite=example.com vhost ignore-cc

5.2.2 使用 `ignore-reload`

在 refresh_pattern 指令中使用 ignore-reload 选项，可完全忽略浏览器重新加载，直接从缓存中提供内容。但在某些情况下可能会提供陈旧的内容。示例：

refresh_pattern .   0 20% 4320 ignore-reload

5.2.3 使用 `reload-into-ims`

使用 reload-into-ims 选项将重新加载降级为 IfModifiedSince 检查，在保留数据准确性的同时减少带宽浪费。示例：

refresh_pattern .   0 20% 4320 reload-into-ims

6. 反向代理模式下的访问控制

6.1 仅反向代理模式

当Squid仅配置为反向代理时，需要限制对正在加速的源服务器的访问。例如，配置的源服务器为 www.example.com 和 www.example.net ，可以使用以下访问控制规则：

acl orign_servers dstdomain www.example.com www.example.net
http_access allow origin_servers
http_access deny all

这些访问控制规则应位于Squid默认访问控制之上，否则客户端请求将被默认访问控制拒绝。

6.2 反向代理和正向代理模式

当Squid同时配置为反向代理和正向代理模式时，设计访问控制时需要注意以下几点：
- 使用代理服务器作为正向代理的客户端应能够访问除黑名单之外的所有网站。
- Squid应接受所有发往正在加速的源服务器的请求，但应拒绝来自黑名单客户端的请求。

例如，子网 192.0.2.0/24 的客户端将使用代理服务器作为正向代理，允许访问除 www.example.net 之外的所有网站，可以编写以下访问规则：

acl our_clients src 192.0.2.0/24
acl blacklisted_websites dstdomain www.example.net
http_access allow our_clients !blacklisted_websites
http_access deny all

通过以上配置和控制，可以充分发挥Squid在反向代理模式下的功能，提高网站性能和安全性。

7. 配置流程总结

为了更清晰地展示Squid反向代理模式的配置过程，下面用mermaid流程图来呈现主要步骤：

graph LR
    A[开始配置Squid反向代理] --> B[配置HTTPS选项]
    B --> C[添加后端Web服务器]
    C --> D[配置代理协议支持]
    D --> E[配置ESI协议支持]
    E --> F[设置日志记录]
    F --> G[配置访问控制]
    G --> H[完成配置]

这个流程图展示了从开始配置到最终完成的主要步骤，每个步骤又包含了多个具体的配置项，如前文所述。

8. 配置要点回顾

8.1 HTTPS选项配置要点

确保系统安装了OpenSSL，可访问 OpenSSL官网获取更多信息，并及时关注其漏洞信息并打补丁。
对于 https_port 指令的各个选项，如 cert 和 key 参数的使用，要明确其指定的文件路径和用途。
选择合适的SSL/TLS协议版本、密码套件和SSL引擎选项时，需根据自身OpenSSL版本进行检查。

8.2 后端Web服务器配置要点

使用 cache_peer 指令添加后端服务器时，根据服务器情况合理选择 originserver 和 forcedomain 选项。
注意配置的服务器地址和端口的正确性。

8.3 代理协议支持配置要点

理解代理协议的工作原理和控制机制，通过 Surrogate-Capability 和 Surrogate-Control 头进行控制。
正确设置 httpd_accel_surrogate_id 和 httpd_accel_surrogate_remote 指令。

8.4 ESI协议支持配置要点

编译Squid时使用 --enable-esi 选项启用ESI支持。
根据实际需求选择合适的ESI解析器，考虑其性能和字符编码处理能力。

8.5 日志记录配置要点

使用 access_log 指令的通用日志格式，使日志符合Apache Web服务器日志格式。
针对浏览器重新加载问题，根据实际情况选择合适的解决方法，如 ignore-cc 、 ignore-reload 或 reload-into-ims 。

8.6 访问控制配置要点

在仅反向代理模式下，限制对加速源服务器的访问，规则应置于默认访问控制之上。
在反向代理和正向代理模式下，平衡客户端访问权限和源服务器请求接受规则。

9. 常见问题及解决方法

9.1 HTTPS连接问题

问题描述 ：客户端无法通过HTTPS连接到Squid反向代理。
可能原因 ：
- OpenSSL未正确安装或版本不兼容。
- https_port 指令配置错误，如端口被占用、证书文件路径错误等。
解决方法 ：
- 检查OpenSSL的安装情况，可通过命令 openssl version 查看版本信息，如有必要进行重新安装或升级。
- 检查 https_port 指令的配置，确保端口未被占用，证书和私钥文件路径正确。

9.2 后端服务器连接问题

问题描述 ：Squid无法将请求转发到后端Web服务器。
可能原因 ：
- cache_peer 指令配置错误，如服务器地址或端口错误。
- 后端服务器本身存在问题，如服务未启动、防火墙限制等。
解决方法 ：
- 检查 cache_peer 指令的配置，确保服务器地址和端口正确。
- 检查后端服务器的运行状态，确保服务已启动，并检查防火墙设置，开放相应端口。

9.3 代理协议控制问题

问题描述 ：代理服务器未按预期进行缓存控制。
可能原因 ：
- httpd_accel_surrogate_id 和 httpd_accel_surrogate_remote 指令配置错误。
- 源服务器返回的 Surrogate-Control 头设置不正确。
解决方法 ：
- 检查 httpd_accel_surrogate_id 和 httpd_accel_surrogate_remote 指令的配置，确保其值符合预期。
- 检查源服务器的配置，确保 Surrogate-Control 头设置正确。

9.4 ESI解析问题

问题描述 ：Squid无法正确解析ESI标记。
可能原因 ：
- 编译Squid时未启用ESI支持。
- 选择的ESI解析器不适合当前的ESI标记。
解决方法 ：
- 重新编译Squid，使用 --enable-esi 选项启用ESI支持。
- 尝试更换ESI解析器，如从 custom 解析器更换为 libxml2 解析器。

9.5 日志记录问题

问题描述 ：日志记录格式不符合预期或日志内容缺失。
可能原因 ：
- access_log 指令配置错误。
- Squid缓存策略导致部分请求未记录。
解决方法 ：
- 检查 access_log 指令的配置，确保使用了通用日志格式。
- 调整Squid的缓存策略，确保需要记录的请求都能被记录。

9.6 访问控制问题

问题描述 ：客户端访问权限不符合预期，如被错误拒绝或允许访问不应访问的资源。
可能原因 ：
- acl 和 http_access 指令配置错误。
- 访问控制规则的顺序不正确。
解决方法 ：
- 检查 acl 和 http_access 指令的配置，确保规则逻辑正确。
- 调整访问控制规则的顺序，确保重要规则优先执行。

10. 总结

通过对Squid反向代理模式的详细配置和优化，我们可以实现高效的HTTP和HTTPS请求处理、灵活的缓存控制、动态内容组装以及严格的访问控制。在实际应用中，需要根据具体的业务需求和网络环境，合理选择和配置各项参数，同时关注常见问题的解决方法，以确保Squid反向代理的稳定运行和性能优化。希望本文能为你在Squid反向代理配置方面提供有价值的参考。