Composer提示不受支持的协议是什么原因_Composer仓库地址格式校验【答疑】-composer-PHP中文网

“不受支持的协议”错误主因是repositories中url与type不匹配：composer 2.x默认禁用http://、git://等非加密或弃用协议；vcs类型必须为.git结尾的有效仓库地址；私有https仓库需带token认证；自建composer仓库须返回content-type: application/json。

composer提示不受支持的协议是什么原因_composer仓库地址格式校验【答疑】

“不受支持的协议”错误几乎总是因为 repositories 里某条配置的 url 和 type 不匹配，或用了 Composer 根本不认的协议前缀（比如 http://、ftp://、git://）。

为什么 `http://` 或 `git://` 会报错

Composer 2.x 默认禁用非加密协议，http:// 被直接拒绝（除非显式设 "secure-http": false）；git:// 协议早已被 Git 官方弃用，且不支持认证，Composer 从 2.2 起不再识别它。

url 写成 "http://gitlab.example.com/pkg.git" → 改为 "https://gitlab.example.com/pkg.git"
url 写成 "git://github.com/user/repo.git" → 改为 "https://github.com/user/repo.git" 或 "git@github.com:user/repo.git"
若必须用 HTTP（如内网 Satis），需在 config 中加："secure-http": false，但仅限可信网络

`type: "vcs"` 却指向非版本控制地址

type: "vcs" 要求 url 必须是可被 git clone、hg clone 或 svn checkout 直接消费的地址。常见误配：

Discussion Composer

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

下载

写成了 GitHub 页面 URL："https://github.com/user/repo" ❌（缺 .git 后缀）
写成了 API 地址："https://gitlab.example.com/api/v4/projects/123" ❌（这不是仓库地址）
写成了打包下载链接："https://example.com/pkg.zip" ❌（这是 dist，不是 vcs）
正确写法只有两种："https://host.com/user/repo.git" 或 "git@host.com:user/repo.git"

私有仓库用了 HTTPS 但没配认证，也被判“协议不支持”

Composer 尝试探测仓库时，如果返回 401 或空响应，会把整个 url 当作无效协议处理——看起来像协议问题，实则是认证失败。

HTTPS 私有库必须带 token："https://oauth2:TOKEN@gitlab.example.com/private/pkg.git"
或全局配置：composer config --global gitlab-token.example.com YOUR_TOKEN
SSH 方式要确保 ssh -T git@gitlab.example.com 能通，且 url 是 "git@gitlab.example.com:private/pkg.git"
Composer 2.2+ 支持在 repositories 内嵌 "auth" 字段，但仅对 GitLab/GitHub 的 API 模式有效，不适用于裸 Git 地址

自建仓库（Satis/SatisPress）返回了错误 Content-Type

Composer 要求 type: "composer" 的仓库，其 /packages.json 响应头必须含 Content-Type: application/json。Nginx/Apache 配置遗漏 MIME 类型，会导致解析失败并报“协议不支持”。

手动访问 https://your-satis.com/packages.json，检查响应头是否含 Content-Type: application/json
Nginx 示例配置：location = /packages.json { add_header Content-Type application/json; }
SatisPress 用户需确认插件已启用，且未被其他 WordPress 插件拦截 JSON 输出
用 curl -I https://your-satis.com/packages.json 快速验证

最容易被忽略的是：这个错误不会告诉你具体是第几个 repository 出的问题。逐条注释掉 repositories 数组中的项，配合 composer diagnose，才能准确定位到那条“看似合法、实则协议失效”的配置。