解决Composer镜像源在多层反向代理下的真实源IP获取瓶颈-composer-PHP中文网

composer本身不传递也不依赖真实客户端ip，所谓多层反向代理下的真实源ip获取瓶颈根本不存在；卡顿或403问题99%源于代理层配置错误，如authorization头丢失、x-forwarded-for误用或缓存策略冲突。

解决composer镜像源在多层反向代理下的真实源ip获取瓶颈

直接结论：Composer 本身不传递、也不依赖真实客户端 IP，所谓“多层反向代理下的真实源 IP 获取瓶颈”根本不存在——你看到的卡顿或 403，99% 是代理层配置错误导致 Authorization 头丢失、X-Forwarded-For 被误用，或缓存策略冲突，不是 Composer 的问题。

为什么 Composer 根本不关心真实 IP

Composer 是纯 HTTP 客户端，只做两件事：发 GET 请求下载 packages.json 和 .zip 文件，然后校验 hash。它不读取、不透传、不校验任何 IP 相关头字段。代理是否保留 X-Real-IP 或 X-Forwarded-For，对 Composer 行为零影响。

真正依赖真实 IP 的环节在服务端（比如你的私有仓库 Nginx 或 Artifactory），而 Composer 只是发起请求的“工具人”。如果你在海外 VPS 上拉不到包，问题一定出在代理链路末端（即你私有仓库所在服务器）的访问控制上，而不是 Composer 没传 IP。

Composer 不解析、不设置、不校验 X-Forwarded-For —— 这个头完全由你配置的 Nginx/Caddy 决定是否加、加多少层
私有仓库返回 403，大概率是后端鉴权模块（如 Laravel Sanctum、JWT middleware）读了 X-Forwarded-For 但没配 trusted_proxies，导致把代理 IP 当成真实 IP 拒绝
如果用了阿里云 OSS 或腾讯云 COS 作 dist 存储，它们根本不看任何转发头，只认 Authorization 或签名 URL —— 此时丢 IP 不影响，丢 Authorization 才真挂

Nginx 反代私有仓库时必须透传的三个头

你在海外 VPS 上用 Nginx 反代国内私有仓库（如 https://pkg.internal.example.com），必须显式透传以下头，否则私有包认证失败：

proxy_set_header Authorization $http_authorization; —— Basic Auth 或 Bearer Token 全靠它，漏掉就 401
proxy_pass_request_headers on; —— 默认开启，但某些自定义配置会关掉，务必确认
proxy_set_header X-Forwarded-For $remote_addr; —— 如果后端鉴权依赖 IP 白名单，这里必须设成最外层真实 IP（不是 $proxy_add_x_forwarded_for，那会叠代理 IP）

错误示范：proxy_set_header X-Forwarded-For ""; 或完全不写该行 → 后端收不到 IP，白名单失效；proxy_hide_header Authorization; → Token 被删，直接 401。

Discussion Composer

围绕关键发现、作用机制、临床相关性及研究局限性展开讨论。适用于撰写或优化任何生物医学论文的“讨论（Discussion）”部分——包括结果解读、与既往文献关联、阐释意外发现、界定研究局限性，以及撰写结论。当用户输入以下任一指令时也会自动触发该功能： - “write my discussion” - “help me discuss my findings” - “how do I compare to prior studies” - “write the limitations par

下载

缓存层篡改 dist.url 导致重定向失败

你用 Caddy/Nginx 缓存私有仓库，并重写 packages.json 中的 dist.url 字段（比如把 https://oss-cn-hangzhou.aliyuncs.com/xxx.zip 改成 https://pkg-proxy-us-east.example.com/xxx.zip），必须同步处理重定向：

原始 OSS URL 返回 302 重定向到临时签名地址，而你的代理没开 proxy_redirect → Composer 收到 302 后直连 OSS，走不通
正确做法：在 proxy 配置里加 proxy_redirect https://oss-cn-hangzhou.aliyuncs.com/ https://pkg-proxy-us-east.example.com/;
更稳妥方案：让代理层自己生成签名 URL（需接入 OSS SDK），而非依赖原始重定向 —— 避免中间跳转暴露密钥或触发限频

验证方式：用 curl -v https://pkg-proxy-us-east.example.com/p/vendor/package/ref.zip，看响应头 Location: 是否指向你代理域名，而不是原始 OSS 域名。

CI/CD 环境下代理配置易被覆盖的坑

GitLab CI 或 GitHub Actions 中，即使你写了 composer config -g http-proxy，也可能被 runner 环境预设的 HTTP_PROXY 环境变量覆盖，导致请求发向错误代理：

Composer 优先级：环境变量 HTTP_PROXY/HTTPS_PROXY > composer config 设置 > 默认直连
CI 中常见现象：composer config -g https-proxy 显示已设，但 composer install -vvv 日志里仍出现 GET https://packagist.org/ → 说明环境变量在覆盖
解决：在 job step 开头加 unset HTTP_PROXY HTTPS_PROXY，再执行 composer 命令；或用 COMPOSER_NO_HTTP_PROXY=1 强制忽略代理