經過三年的開發，Squid 代理伺服器的新穩定版本 5.1 已經發布，可以用於生產系統（5.0.x 版本為測試版）。
5.x 分支穩定後，後續只會修復漏洞和穩定性問題，並進行一些小的最佳化。新功能的開發將在新的實驗性 6.0 分支中進行。我們建議先前穩定版 4.x 分支的使用者計畫遷移到 5.x 分支。
Squid 5.1 主要新特性
由於授權問題，新版本已棄用與 Berkeley DB 格式的相容性。 Berkeley DB 5.x 分支已多年未維護，仍存在未修復的漏洞，升級到新版本無法更改 AGPLv3 許可，而 AGPLv3 許可的要求也適用於使用 Berkeley DB 作為庫的應用程式。 Squid 採用 GPLv2 許可，而 AGPL 與 GPLv2 不相容。
該專案已從 Berkeley DB 遷移到 TrivialDB 資料庫管理系統。與Berkeley DB 不同，TrivialDB 針對資料庫的並發並行存取進行了最佳化。目前仍保留對 Berkeley DB 的支持，但建議在“ext_session_acl”和“ext_time_quota_acl”處理程序中使用“libtdb”存儲類型，而不是“libdb”。
此外，還添加了對 RFC 8586 中定義的 HTTP CDN-Loop 標頭的支持，該標頭允許在使用內容交付網絡時檢測循環（標頭提供保護，防止請求在 CDN 之間由於某種原因重定向期間返回到原來的CDN，形成無限循環）。
此外，SSL-Bump 機制允許攔截加密的 HTTPS 會話的內容，現在增加了對透過 cache_peer 中指定的其他代理伺服器重定向偽造的 HTTPS 請求的支持，該支援使用基於 HTTP CONNECT 方法的常規隧道（不支援透過 HTTPS 傳輸，因為 Squid 還不能在 TLS 中傳輸 TLS）。
SSL-Bump 在收到第一個攔截到的 HTTPS 請求後，會與目標伺服器建立 TLS 連線並取得其憑證。然後，Squid 使用從伺服器收到的真實證書的主機名稱建立一個偽造證書，並在與客戶端互動時使用該偽造證書來冒充請求的伺服器，同時繼續使用與目標伺服器建立的 TLS 連線來接收資料。
值得注意的是，用於與外部內容驗證系統整合的ICAP （互聯網內容適配協議）的實現增加了對資料附加機制的支持，允許將額外的元資料標頭附加到回應中，放置在訊息正文之後。
而不是考慮“dns_v4_first»要確定 IPv4 或 IPv6 地址族的使用順序， 現在考慮了 DNS 中響應的順序- 如果在等待 IP 地址解析時首先出現來自 DNS 的 AAAA 響應，則將使用生成的 IPv6 地址。 因此，首選地址族設置現在在防火牆、DNS 中或在啟動時使用“–disable-ipv6”選項完成。
提議的更改將加快配置 TCP 連接的時間，並減少 DNS 解析延遲對性能的影響。
重定向請求時，使用「Happy Eyeballs」演算法，該演算法會立即使用接收的 IP 位址，而無需等待所有可能可用的目標 IPv4 和 IPv6 位址解析完畢。
為了在“external_acl”指令中使用，已添加“ext_kerberos_sid_group_acl”驅動程序，以使用 Kerberos 對 Active Directory 中的驗證組進行身份驗證。 OpenLDAP 包提供的 ldapsearch 實用程序用於查詢組名。
添加了 mark_client_connection 和 mark_client_pack 指令以將 Netfilter (CONNMARK) 標籤綁定到單個數據包或客戶端 TCP 連接
最後，文中提到，按照已發布的 Squid 5.2 和 Squid 4.17 版本中的步驟，以下漏洞已修復：
- CVE-2021-28116 - 處理特製 WCCPv2 消息時信息洩漏。 該漏洞允許攻擊者破壞已知 WCCP 路由器列表並將流量從代理客戶端重定向到其主機。 該問題僅在啟用了 WCCPv2 支持的配置中以及在可能欺騙路由器的 IP 地址時才會出現。
- CVE-2021-41611：驗證允許使用不受信任的證書訪問的 TLS 證書時出錯。