解决Composer镜像源在非标准端口下的协议解析异常-composer-PHP中文网

composer 不支持镜像 url 中含非标准端口（如 :8080），会在 json 解析阶段直接报错，拒绝加载仓库；必须通过反向代理隐藏端口，或改用 type: "package" 手动定义包。

解决composer镜像源在非标准端口下的协议解析异常

镜像源 URL 里带非标准端口（如 :8080）会直接触发协议不支持错误

Composer 解析 repositories 配置时，对 URL 的合法性校验非常严格。一旦你在镜像地址中写入类似 http://mirrors.example.com:8080/composer/ 这样的 URL，即使服务本身能通，Composer 也会在 JSON 解析阶段就报错——它根本不会尝试发起请求，而是直接拒绝加载该仓库。

原因在于：Composer 内部用正则或白名单方式校验 URL scheme + host + port 组合，:8080 这类显式端口未被纳入安全端口列表（仅接受默认的 :80 和 :443），导致整个 type: "composer" 仓库被判定为非法。

错误现象通常是 unrecognized repository type 或 No valid composer repositories found，但你明明写了 "type": "composer"
这种报错和 curl -I 能否通完全无关——它卡在配置解析层，不是网络层
哪怕你把端口改成 :80 或 :443，只要 URL 中显式写出，仍可能被拒（部分旧版 Composer 会宽松处理，但 ≥2.5 默认收紧）

非标准端口镜像必须走反向代理，不能直接配进 composer.json

想用运行在 :8080 上的私有镜像？别把端口写进 repositories。正确做法是前置一层反向代理，把 https://my-mirror.internal/（无端口）指向后端 http://127.0.0.1:8080。Composer 只认干净域名，不认端口。

Nginx 示例：location / { proxy_pass http://127.0.0.1:8080/; }，然后配 https://my-mirror.internal/ 到 Composer
Apache 同理，用 ProxyPass，确保最终对外暴露的是标准 HTTPS 端口
本地开发可临时用 nginx -p $(pwd) -c nginx.conf 起一个最小代理，比改 Composer 源码现实得多

手动验证 URL 是否被 Composer 接受的最快方法

别等 composer install 报错才排查。直接用 PHP 命令行模拟 Composer 的解析逻辑：

Discussion Composer

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

下载

php -r "
$cfg = json_decode(file_get_contents('composer.json'), true);
if (isset($cfg['repositories'])) {
    foreach ($cfg['repositories'] as $repo) {
        if (isset($repo['url']) && preg_match('#^https?://[^/]+(?::[0-9]+)?/#i', $repo['url']) === 0) {
            echo "URL 格式非法: " . $repo['url'] . "\n";
        }
    }
}"

这段脚本会立刻告诉你哪条 url 因含非标准端口或其他格式问题被拒。它复现了 Composer 实际使用的正则逻辑，比看文档更快定位问题点。

如果输出空行，说明所有 URL 都通过基础校验
如果输出某条 URL，重点检查它是否含 :8080、:3000 等非标端口，或末尾漏了 /
注意：这个检查不代替 curl -I，它只管“能不能被 Composer 读”，不管“服务能不能通”

公司内网镜像用了非标端口，又没法加反代？只能降级兼容

极少数场景下（比如测试环境强约束），你确实无法加反向代理。这时唯一合规的绕过方式是：改用 type: "package" 手动定义包，绕过 URL 解析。

例如，你想拉取一个只在 http://10.0.1.5:8080/pkg.zip 提供的包：

{
    "repositories": [{
        "type": "package",
        "package": {
            "name": "vendor/internal-pkg",
            "version": "1.0.0",
            "dist": {
                "url": "http://10.0.1.5:8080/pkg.zip",
                "type": "zip"
            },
            "autoload": {"psr-4": {"Vendor\": "src/"}}
        }
    }]
}