所以我们正在构建一个基于web的音频流平台，其中音频文件存储在blob存储中。我们正在为blob创建一个SAS URL，然后将其提供给javascript播放器(aurora)。
这在大多数情况下工作得很好，但是当我切换跟踪很多时，在某一点上，我开始收到403响应文件的HEAD请求。
如果我在firebug中单击RESEND，它只是重新发送完全相同的请求，那么有时我仍然得到相同的403错误，但过了一会儿请求将再次成功，这意味着URL格式正确。
下面是我得到的完整响应
403 Server failed to authenticate the request. Make sure the value of
Authorization header is formed correctly including the signature.
Transfer-Encoding: chunked Server: Microsoft-HTTPAPI/2.0
x-ms-request-id: <removed>
access-control-expose-headers:
Content-Type,Accept-Ranges,Content-Encoding,Content-Length,Content-Range
Access-Control-Allow-Origin: * Date: Fri, 12 Aug 2016 06:31:58 GMT
我开始认为对blob存储的某种限制被触发，例如最大连接量或带宽限制，甚至可能是DOS防御机制。有人有什么建议吗?
我读过一些关于存储中的诊断的文章，但它们都指的是旧的Azure门户。我的存储帐户只在新的门户中可见。所以我的子问题是:谁能告诉我一种方法来诊断为什么请求被拒绝，使用新的Azure门户?
编辑:我使用Azure Management Studio查看了存储帐户的日志。我在那里发现了这条日志，它指定了一个'SASNetworkError':
1.0;2016-08-12T10:26:27.7337647Z;GetBlob;SASNetworkError;206;19002;6;sas;;[xxx];blob;"https://[xxx].blob.core.windows.net:443/files/[xxx].flac?sv=2015-04-05&sr=b&si=flacpolicy636065943797947863&sig=XXXXX&sip=[xxx]";"/[xxx]/files/[xxx].flac";8f7d48a3-0001-0017-5983-f499a7000000;0;[xxx]:40690;2015-04-05;637;0;499;0;0;;;""0x8D35C8CDDD72689"";Monday, 04-Apr-16 13:27:27 GMT;;"Mozilla/5.0 (Windows NT 10.0; WOW64; rv:47.0) Gecko/20100101 Firefox/47.0";"http://[xxx].azurewebsites.net/";
看起来这是错误的原因，但是我不知道是什么出错了
我发现了导致错误的原因:一个容器上最多有5个命名的访问策略。我正在为每个剧本创建一个新的访问策略，并以新名称注册。我通过创建一个新策略并将其传递给GetSharedAccessSignature调用来解决这个问题。
根据这篇文章，
SAS请求由于网络错误而失败。最常见的情况是客户端在超时到期前过早关闭连接。
是否有一个网络中介，如代理，正在关闭连接?