🔗 Squid 配置：顺序很重要！
- 顺序很重要
- 顺序是关键
这是 Squid 用户帮助列表中重复最多的评论（遥遥领先）。Squid 传统的“混乱的配置行”在通知问题所在方面也并不特别有用。
🔗 为什么？
Squid 从上往下处理其配置文件。从左到右。在处理过程中创建内部配置信息。
为了打个比方，有一个简单的日常程序可以用来进门。解锁、打开、穿过。顺序错了。例如，“解锁、穿过、打开”可能有效。但按这种方式操作可能会很痛苦，而且你也不会最终出现在门厅的另一边。
同样，Squid 中存在一些单独配置的操作组。但顺序决定了最终情况。
🔗 模式
现代 Squid 同时运行多种操作模式。
顺序 http_access 前向代理和反向代理配置选项决定了反向代理网站访问者是否能够访问该网站。它们还决定了该网站是否能够执行 HTTPS、AJAX、JSON 或除了普通 HTTP 之外的其他高级网站操作。有关具体的顺序细节，请参阅相关的 SquidFaq/ReverseProxy#How_do_I_set_it_up 示例。通常反向代理需要放在前面。
顺序和放置 debug_options 指令决定了在处理配置文件期间以及之后在 Squid 正常运行时运行哪些调试级别。
🔗 认证
顺序 auth_param program 指令决定了 Squid 如何向浏览器报告认证选项。这对执行哪种类型的认证具有可见的影响。有关详细信息和推荐顺序，请参阅 Features/Authentication。
acl proxy_auth 和使用 %LOGIN 的 external_acl_type 必须定义在 auth_param 之后。Squid 会警告此处正在使用但未设置的认证。
使用 %LOGIN 的 external_acl_type 如果缺少这些凭据，将会触发认证挑战。这些测试的放置会影响它们周围哪些规则需要认证。
同样，在访问控制行上从左到右的 acl 测试认证的放置决定了测试是绕过、失败还是触发认证挑战。
🔗 访问控制
acl 定义行必须在它们被引用使用之前的任何地方之前指定。
单个访问控制的顺序会影响同一类型的其他行。例如，每个 http_access 按顺序运行并相互影响，但不会影响它们之间的任何 cache_peer_access。
每种类型的访问指令都是如此。有关访问类型的列表，请参阅 SquidFaq/SquidAcl#Access_Lists。
每个访问控制行上单个单词的顺序甚至更关键。这可能意味着访问控制行匹配或跳过的区别。或者 Squid 每秒能处理 300 个请求还是 3000 个请求。有关单个行单词顺序如何工作，请参阅 SquidFaq/SquidAcl#Common_Mistakes。
🔗 主要事务里程碑
典型的 HTTP 事务会经过一系列检查，并可能与外部辅助程序/服务共享。由于这些检查和服务可能会修改事务和/或其元数据，因此了解它们的执行顺序通常至关重要。例如，请求的目标 URI 是在存储 ID 辅助程序运行之前还是之后被重写？目前没有全面的文档涵盖所有主要的事务里程碑，但本节可以回答许多相关的常见问题。
🔗 回调顺序
大多数 HTTP 请求都应用以下检查和调整顺序。此顺序在 Squid 解析请求头之后开始，在 Squid 从缓存或源服务器开始满足请求之前结束。此处按执行顺序列出检查：
- 主机头伪造检查
- http_access 指令
- ICAP/eCAP 适应
- 重定向器
- adapted_http_access 指令
- store_id 指令
- clientInterpretRequestHeaders()
- cache 指令
- ToS 标记
- NetFilter (nf) 标记
- ssl_bump 指令
- 回调顺序错误处理
失败的检查可能会阻止后续检查运行。
典型的 HTTP 事务（即一对 HTTP 请求和响应消息）会经历一次上述顺序。然而，多个事务可能参与单个“网页下载”的处理，这会让 Squid 管理员感到困惑。虽然所有有经验的 Squid 管理员都知道单个网页可能包含数十甚至数百个资源，每个资源都会触发一个 HTTP 事务，但即使请求单个资源，甚至使用 curl 或 wget 等简单命令行工具时，也可能发生多个事务。
内部 Squid 请求可能会引起更多混乱。例如，当使用 SslBump 时，Squid 可能会为给定的 TLS 连接创建多个伪 CONNECT 事务，并且每个 CONNECT 都可能经历上述过程。如果您对拦截的端口 443 流量使用 SslBump，那么在 Squid 接受新连接后不久，SslBump 会创建一个具有 TCP 级别信息的伪 CONNECT 请求，该 CONNECT 请求将经历上述顺序（匹配任何 SslBump1 ACL）。如果在第一个 SslBump 步骤中匹配了“ssl_bump peek”或“ssl_bump stare”规则，那么 SslBump 代码将获取 SNI 并创建第二个伪 CONNECT 请求，该请求将再次经历相同的顺序。
同样，(S)FTP 原生服务将 Stream Transaction 中的每条消息转换为各种 HTTP 消息，这些消息应该经历上述过程。
您的 Squid 指令及其辅助程序必须准备好处理每个连接的多个CONNECT 请求。
🔗 其他
其他一些交互更简单，但顺序仍然很重要。
- refresh_pattern - 从上到下，第一个匹配的模式获胜。
- delay_pools + delay_class + delay_parameters - 必须按以下顺序添加：pools，class，parameters。
- cache_peer - 单个 cache_peer 条目的顺序会影响默认和第一个可用 peer 的选择。
回到 FAQ 索引
导航： 网站搜索、网站页面、分类、🔼 向上