我太懂你这种头疼的感觉了——好不容易把apt的HTTPS解密调试通了，结果其他程序明明乖乖认了系统的http(s)_proxy变量，却不按规矩发HTTP CONNECT请求，直接就往Squid端口撞，完全不走隧道那套流程。我之前碰过类似的情况，给你梳理几个排查和解决的方向：

先查Squid的CONNECT权限配置 #

Squid默认只会允许CONNECT到标准的HTTPS端口（比如443），而且得有明确的规则放行CONNECT方法。你先打开Squid的配置文件（一般是/etc/squid/squid.conf），检查这几行：

acl SSL_ports port 443 8443  # 这里要包含你所有需要走HTTPS的端口，比如有些程序用8443
acl CONNECT method CONNECT
http_access allow CONNECT SSL_ports

要是你有自定义的端口没加进SSL_ports里，或者http_access规则里有先拒绝CONNECT的条目，那程序自然发不了CONNECT请求。记得改完配置后重启Squid：systemctl restart squid

确认客户端代理变量的设置姿势 #

很多人在这里踩坑——设置https_proxy的时候，一定要用http://开头的代理地址，而不是https://！因为HTTPS代理的本质是通过HTTP隧道建立连接，客户端要先给Squid发HTTP CONNECT请求，再在隧道里做TLS握手。

正确的环境变量设置应该是这样的（可以写到/etc/profile或者/etc/environment里让全局生效）：

export http_proxy=http://你的SquidIP:3128
export https_proxy=http://你的SquidIP:3128
export no_proxy=localhost,127.0.0.1,你的内部域名或IP段

你可以先在终端里手动export这些变量，再用echo $https_proxy确认值对不对，别不小心写成了https://xxx，那样程序根本不会发CONNECT请求。

用curl做针对性测试 #

你提到curl也有这个问题，那咱们用curl的verbose模式抓细节：

curl -v https://example.com

正常情况下，输出里应该能看到这段：

* Establish HTTP proxy tunnel to example.com:443
* CONNECT example.com:443 HTTP/1.1

如果看不到，先检查curl有没有被特殊配置（比如~/.curlrc里有没有硬编码代理或者禁用代理的设置），或者是不是系统里的curl编译时没加代理支持（不过Debian默认的curl肯定支持）。

检查Squid的日志找线索 #

去看Squid的访问日志/var/log/squid/access.log，找那些有问题的请求记录：

• 如果日志里显示的是CONNECT example.com:443，说明客户端已经发了CONNECT请求，那问题可能出在Squid的SSL bump配置上；
• 如果日志里是GET https://example.com/ HTTP/1.1，那就是客户端错误地把HTTPS请求当成普通HTTP请求发了，十有八九是代理变量设置错了（比如https_proxy设成了https://）。

调整SSL bump的覆盖范围 #

既然apt的HTTPS能解密，说明你的SSL bump配置是有效的，但可能只针对apt的流量做了设置。你可以把SSL bump规则改成对所有流量生效：

ssl_bump peek all
ssl_bump bump all

这样不管是apt还是其他程序的HTTPS流量，Squid都会先peek握手信息，再进行bump解密。当然，如果你只想针对特定程序或域名，也可以用acl来限定范围。

排查程序本身的代理支持 #

极少数程序可能本身不支持通过HTTP隧道处理HTTPS请求，这时候你得查程序的文档，看有没有专门的代理配置项，比如有些Java程序需要在启动参数里加-Dhttps.proxyHost=xxx而不是依赖系统环境变量。

备注：内容来源于stack exchange，提问作者bdrun33