这个坑值得记一笔。在 Java 服务里用 REST 调 Azure 上的 gpt-4o，资源在 East US，请求地址是 https://myaoai.openai.azure.com/openai/deployments/chat/chat/completions?api-version=2024-06-01，返回 401，原文 Access denied due to invalid subscription key or wrong API endpoint，同一个 key 在同事的 Python 脚本里能通。
刚开始盯着「api-version 用了该区域尚未开放的预览日期」，折腾了半个多小时，排掉了。
原因不止一个，得分开看。请求头里用的是 api-key 还是 Authorization Bearer 没对上；资源名写成了显示名 endpoint 域名拼错一位；key 属于另一个订阅 资源组迁移后配置没更新。
动手时先在门户里核对资源和真实 endpoint
az cognitiveservices account show --name myaoai --resource-group rg-ai --query properties.endpoint随后用 curl 带 api-key 头打同一个部署
curl -i 'https://myaoai.openai.azure.com/openai/deployments/chat/chat/completions?api-version=2024-06-01' -H "api-key: $AZURE_KEY" -H 'Content-Type: application/json' -d '{"messages":[{"role":"user","content":"hi"}]}'接着列出资源下的部署名 确认路径里的 chat 存在
az cognitiveservices account deployment list --name myaoai --resource-group rg-ai -o table剩下的就是把 endpoint 和 api-version 收进配置后重启服务
python -c "import os;print(os.getenv('AZURE_OPENAI_ENDPOINT'))"同样的操作我在测试机上先走了一遍，线上只做验证过的部分。
这台环境是别人交接的，不少默认值被动过，只能一项项核。
别只看报错消失，验证要多做一步。同一个 key 返回 200，响应体里 model 字段是 gpt-4o，服务日志中的 endpoint 与门户一致。
Azure 的鉴权头和 OpenAI 官方完全不同，api-key 与 Bearer 混用会直接 401，先看请求头再看 key。报错文案容易误导，真正的原因往往在相邻那一层的日志里。