我之前在Docker里部署类似的API认证服务时也踩过一模一样的坑，结合你的情况，这几个方向大概率能帮你找到问题：

• 环境变量传递不到位
  本地用gunicorn跑的时候，你的API密钥可能是从终端环境变量或者本地.env文件加载的，但Docker容器默认不会继承这些环境配置。

  • 如果是用docker run启动容器，一定要用-e参数显式传递密钥：

    docker run -e COINBASE_API_KEY=your-actual-key -e COINBASE_API_SECRET=your-actual-secret your-image-name
    

  • 如果用docker-compose，要在配置文件的environment块里写清楚变量，或者用env_file指定你的.env文件路径（注意要确保docker-compose能读到这个文件，不需要把它复制进镜像）。

• 密钥带了隐藏字符或转义问题
  有时候复制密钥到Docker变量时，会不小心带了换行符或者空格，或者像=、/这类特殊字符在Shell命令里被错误解析。

  • 你可以在代码里用repr(api_key)代替直接打印，这样能看到字符串里的隐藏字符（比如\n），确认密钥是不是和你在Coinbase后台复制的完全一致。
  • 如果密钥包含特殊字符，在docker run命令里一定要用双引号把值包起来，避免被Shell解析成其他内容。

• IP白名单限制
  本地运行时用的是你电脑的公网IP，但Docker容器的出口IP可能和本地不一样——如果你的Coinbase API密钥设置了IP白名单，容器的IP不在列表里就会触发认证错误。

  • 去Coinbase的API设置页检查IP白名单，把Docker宿主机的公网IP（或者容器实际的出口IP）加进去。
  • 顺便确认下API密钥的权限是否符合你应用的需求，权限不足有时候也会返回“invalid api key”这种误导性错误。

• 构建镜像时的环境变量失效
  看你的Dockerfile开头是python:3.5，如果构建过程中你尝试过加载环境变量（比如RUN source .env），那这完全没用——Docker的每一层RUN都是独立环境，构建阶段的变量不会保留到运行时。

  • 绝对不要把密钥硬编码到Dockerfile里，也不要把.env文件复制到镜像里（除非是完全私密的测试镜像），所有敏感信息都要在容器运行时传递。

最后给个小技巧：可以直接进入容器检查环境变量是否正确，执行docker exec -it your-container-id bash，然后用echo $COINBASE_API_KEY和echo $COINBASE_API_SECRET看看变量值是不是和本地一致，这能快速排除环境变量的问题。

内容的提问来源于stack exchange，提问作者Aurélien Pigot Bennour