Composer不记录代理日志，需用mitmproxy、cntlm或cURL trace等外部手段审计；CI/CD中应固化日志采集，关注packagist.org的200响应及/advisories非空JSON，警惕lock校验、私有仓库直连和COMPOSER_NO_AUDIT=1导致的日志缺失。
Composer 本身不记录网络代理行为日志，也无内置审计能力；所谓“代理日志审计”必须靠外部手段补位，否则你看到的只是“成功/失败”，根本不知道它连了谁、传了啥、卡在哪。
为什么 composer config --global http-proxy 不等于有代理日志
Composer 的 http-proxy 和 https-proxy 配置只是告诉它“把请求发给谁”，不开启任何日志输出。默认情况下，所有代理通信静默完成，没有请求 URL、响应状态、耗时、重试次数等字段。你执行 composer install 卡住了？不知道是代理没响应、认证失败、还是隧道被防火墙截断。
- 它不会写入
composer.log或任何本地文件（除非你手动重定向 stderr） -
COMPOSER_MEMORY_LIMIT或COMPOSER_DISABLE_TTY这类环境变量也不触发日志增强 - 即使加了
-v（verbose），输出也仅限于包解析流程，不包含底层 cURL 的 CONNECT 请求细节
真正能抓到代理通信日志的三种实操方式
想审计 Composer 的代理行为，得在它下面再搭一层可观测层：
Discussion Composer
下载
围绕关键发现、作用机制、临床相关性及研究局限性展开讨论。适用于撰写或优化任何生物医学论文的“讨论（Discussion）”部分——包括结果解读、与既往文献关联、阐释意外发现、界定研究局限性，以及撰写结论。当用户输入以下任一指令时也会自动触发该功能： - “write my discussion” - “help me discuss my findings” - “how do I compare to prior studies” - “write the limitations par
-
用 mitmproxy 或 Charles 拦截本地代理流量：把
https-proxy设为http://127.0.0.1:8080，启动 mitmproxy 监听该端口，所有 Packagist 请求（包括/packages.json、/p2/路径、/advisoriesAPI）都会被捕获，含完整 header、body、证书链、响应时间 -
改用 cntlm + 日志开关：如果公司用 NTLM 代理，cntlm 支持
-l /var/log/cntlm.log记录每条 CONNECT 请求；注意它只记隧道建立动作，不记录 HTTP 层内容 -
封装 wrapper 脚本 + cURL trace：写个 shell 脚本替代
composer命令，对关键网络操作（如curl -x $PROXY获取packages.json）加-v --trace-ascii /tmp/composer-curl.trace，再用grep "CONNECT\|HTTP/"提取关键行
CI/CD 中如何让代理行为可追溯、可归档
流水线里不能靠人工开 mitmproxy，得固化日志采集点：
- 在 GitHub Actions 或 GitLab CI 的 job 开头，先运行
composer config --global https-proxy http://127.0.0.1:8080，再启动mitmdump -s audit.py -p 8080 > proxy-audit-$(date +%s).log &（audit.py可过滤出 Packagist 域名并提取Host和User-Agent） - 所有
composer install或composer audit命令后，加kill $(pgrep mitmdump)并上传proxy-audit-*.log到 artifact 存储 - 关键判断依据不是“有没有日志”，而是日志里是否出现
packagist.org的200 OK响应，以及/advisories请求是否返回非空 JSON——这比看composer install成功更可信
最容易被忽略的审计盲区
即使你把 mitmproxy 日志全抓下来，仍有三处默认不可见：
-
composer.lock文件校验阶段走的是本地文件系统，不经过代理，也不会被记录 - 私有仓库（如
type: "package"或repositories[].url指向内部 Git）的请求，若未显式配置http-proxy，会 fallback 到直连，且无任何 warning -
COMPOSER_NO_AUDIT=1环境变量会跳过/advisories请求，但 mitmproxy 日志里连这条请求都看不到——它根本没发出去
