Nginx缓存Azure Blob认证失败,返回403错误寻求解决方案
Nginx代理Azure Blob存储时403认证失败问题
错误信息
HTTP/1.1 403 Server failed to authenticate the request. Make sure the value of Authorization header is formed correctly including the signature. Server: nginx/1.23.3 Date: Tue, 14 Feb 2023 04:50:24 GMT Content-Type: application/xml Content-Length: 408 Connection: keep-alive x-ms-request-id: fb70e59e-701e-0040-172f-40ef6a000000 Access-Control-Expose-Headers: content-length Access-Control-Allow-Origin: *
当前Nginx配置
events { worker_connections 1024; } # Nginx configuration file http { # Define the proxy cache settings proxy_cache_path /var/cache/nginx levels=1:2 keys_zone=static_cache:10m inactive=60m; proxy_cache_valid 200 60m; proxy_cache_valid 404 1m; proxy_cache_bypass $http_pragma; proxy_cache_revalidate on; server { listen 80; server_name <nginx-host-name>; location / { proxy_pass https://<my-blob-account>.blob.core.windows.net/nasunifiler64e2bc43-41f8-424d-8f4d-ed85d8fd1ab1-5/; proxy_set_header Host <my-blob-account>.blob.core.windows.net; proxy_set_header Authorization "SharedKey my-blob-account:<access-key>"; proxy_http_version 1.1; proxy_set_header Connection ""; } } }
问题分析与解决方案
1. Authorization头部错误
你当前的Authorization头配置完全错误。Azure的SharedKey认证机制要求:
- 签名不是直接使用原始的
<access-key>,而是需要对请求的关键参数(包括请求方法、日期、资源路径、HTTP头等)进行HMAC-SHA256加密,再经过Base64编码生成的。 - 静态硬编码的Authorization头无法适配每次请求的动态参数(比如实时日期),必然导致认证失败。
2. 额外请求头要求
Azure Blob存储的认证依赖请求的时间戳,必须确保请求包含正确的Date或x-ms-date头,且请求时间与Azure服务器时间差不超过15分钟。Nginx默认会传递客户端的Date头,但如果有自定义修改,需保证该头的准确性。
3. 可行解决方案
方案一:设置Blob容器公开访问(适合公开资源)
如果你的Blob内容允许公开访问,可将容器权限设置为“匿名读取”,此时无需Authorization头,Nginx可直接代理缓存。方案二:使用Nginx第三方模块动态生成签名
使用专门的Nginx模块(如ngx_azure_auth),该模块会根据每次请求的参数实时计算符合要求的SharedKey签名,自动填充Authorization头,解决静态签名的问题。方案三:切换到SAS令牌(临时访问权限)
生成带有有效期的SAS令牌,将其附加到Blob的请求URL中,Nginx代理时直接使用包含SAS的URL,无需手动设置Authorization头。
为什么azcopy/curl能成功?
azcopy和curl等工具会自动根据请求参数计算并生成正确的SharedKey签名,而你在Nginx中直接使用原始密钥,不符合Azure的认证规则,所以无法通过验证。
内容的提问来源于stack exchange,提问作者GoneCase123
相关产品推荐
相关产品推荐

