Azure Storage Java：API 与令牌请求的代理路由
配置 Java SDK 代理时，既要检查 Azure Storage 请求，也要检查凭证令牌请求。
在存储客户端的 HTTP 传输上配置代理只回答一个问题：该传输如何发送存储请求。而身份凭证可能使用另一个 HTTP 客户端来获取令牌。
这一区别解释了一个看似常见的矛盾：存储终结点可以通过代理访问，但 SDK 在发送预期操作之前就失败了。该失败可能属于针对身份终结点的凭证获取。
首先记录哪个目标失败了。然后检查提供给存储构建器的 HTTP 客户端，以及凭证实现所使用的配置。遵循每种传输受支持的代理选项。对于在允许的公共代理路由上可公开访问的存储和令牌终结点，HTTP 代理列表提供候选终结点；不要假设一个构建器的设置会重新配置应用中的每个对象。
| 阶段 | 有用的证据 |
|---|---|
| 令牌获取 | 身份终结点、所选客户端、代理质询或连接错误 |
| 存储请求 | 存储终结点、已配置的管道、最终响应或传输失败 |
将代理账户与 Azure 凭证分开。成功的代理登录只授予一条路由；目标服务仍会对 Azure 操作进行授权。
历史上的回答使用了几代 Azure Storage Java 类，包括较旧的 OperationContext 和管道 API。将示例与应用当前使用的 SDK 和 HTTP 传输相匹配。对于 Data Lake SDK，存储与身份共用的 HTTP 客户端设置展示了两个构建器输入。为解决代理问题而重新引入过时的客户端类型，会多出一条需要调试的配置路径。
在日志中使用安全的终结点标识符。存储 URL 可能包含访问令牌，完整的代理 URL 可能包含密码。