结合你描述的场景（Windows正常、Linux/容器失效、离线环境），我梳理了几个可能的核心原因和对应的解决办法，咱们一步步排查：

一、Cargo配置加载优先级被干扰 #

虽然你把config.toml放在项目根目录的.cargo下，但Cargo的配置加载遵循系统级→用户级→项目级的优先级顺序。如果Linux/容器环境中存在全局（/etc/cargo/config.toml）或用户级（~/.cargo/config.toml）的配置文件，里面的源设置可能覆盖了你项目的配置，导致Cargo依然指向crates.io。

解决办法： #

• 先验证当前生效的配置：在容器中执行

  cargo config get source
  

  查看输出中crates-io的replace-with是否确实指向artifactory，如果不是，说明上层配置在干扰。
• 临时绕过上层配置：执行cargo build时强制指定配置项

  cargo build --config 'source.crates-io.replace-with="artifactory"'
  

• 清理干扰配置：如果是用户级配置问题，可以临时重命名~/.cargo/config.toml后再测试。

二、HTTP Git仓库的访问限制（Git/Cargo安全策略） #

你的自定义源是HTTP协议的Git仓库，Linux环境下的Git或Cargo内置的Git客户端可能默认拒绝不安全的HTTP连接，即使你添加了[net] allow-insecure = true也可能没生效（比如配置项位置不对，或者Git本身的ssl验证没关闭）。

解决办法： #

1. 先验证Git能否单独访问索引仓库：在容器中执行

   git clone http://bitbucket/scm/<some path>/cargo-index.git
   

   • 如果克隆失败，说明是Git的配置问题：
     • 关闭Git的SSL验证（因为你的源没有HTTPS）：

       git config --global http.sslVerify false
       

     • 检查DNS解析：执行ping bitbucket确认容器能正确解析这个主机名（Windows正常但容器可能存在DNS配置差异）。
2. 确保Cargo使用系统Git并允许不安全连接：完善你的config.toml配置，确保配置项放在正确的位置：

   [source]
   [source.artifactory]
   registry = "http://bitbucket/scm/<some path>/cargo-index.git"
   [source.crates-io]
   replace-with = "artifactory"
   [http]
   timeout = 120
   [net]
   git-fetch-with-cli = true  # 强制使用系统Git
   allow-insecure = true      # 允许不安全的HTTP连接
   

三、自定义Cargo索引结构不正确 #

如果你的Bitbucket上的cargo-index仓库结构不符合Cargo的要求（比如缺少config.json，或者dl字段配置错误），Cargo会无法识别这个源，从而 fallback 到默认的crates.io。

解决办法： #

• 检查索引仓库的根目录是否存在config.json，内容应该类似：

  {
    "dl": "http://bitbucket/scm/<some path>/crates/{crate}/{version}",
    "api": "http://bitbucket/scm/<some path>"
  }
  

  确保dl路径正确指向你的crates包存储地址。
• 手动拉取索引：在容器中执行

  cargo update --index http://bitbucket/scm/<some path>/cargo-index.git
  

  强制Cargo拉取自定义索引，避免因索引未同步导致的源失效。

四、文件权限问题 #

通过ADD . /project复制到容器中的.cargo/config.toml可能权限不正确（比如所有者是root），而你执行cargo build用的是普通用户，导致Cargo无法读取项目级配置，转而使用默认配置。

解决办法： #

• 在Dockerfile中添加权限设置：

  ADD . /project
  RUN chown -R nonroot:nonroot /project/.cargo  # 替换为你使用的普通用户
  USER nonroot
  WORKDIR /project
  RUN cargo build
  

• 检查文件权限：在容器中执行

  ls -l /project/.cargo/config.toml
  

  确保当前执行cargo build的用户有读权限。

五、离线环境下的Cargo fallback逻辑 #

因为主机处于离线状态，如果Cargo无法连接到自定义源，可能会触发 fallback 到默认源的逻辑（即使配置了replace-with）。但你的错误是无法解析static.crates.io，说明Cargo确实在尝试默认源，这大概率还是前面的配置加载或源访问问题导致的。

额外验证步骤： #

• 在容器中执行cargo build -v（verbose模式），查看输出中的源加载日志，确认Cargo是否尝试连接你的自定义Bitbucket源，以及失败的具体原因。

内容的提问来源于stack exchange，提问作者Alden Mirek