Azure Key Vault .NET: Proxy Settings for Secrets and Token Requests

Assign the same Azure Core transport to SecretClientOptions and ClientSecretCredentialOptions before starting either request path.

var handler = new System.Net.Http.HttpClientHandler
{
    UseProxy = true,
    Proxy = new System.Net.WebProxy(
        "http://proxy.example.net:8080")
};

var transport = new Azure.Core.Pipeline.HttpClientTransport(handler);

var credential = new Azure.Identity.ClientSecretCredential(
    tenantId, clientId, clientSecret,
    new Azure.Identity.ClientSecretCredentialOptions
    {
        Transport = transport
    });

var vault = new Azure.Security.KeyVault.Secrets.SecretClient(
    new Uri(vaultUrl),
    credential,
    new Azure.Security.KeyVault.Secrets.SecretClientOptions
    {
        Transport = transport
    });

Use the application's real vaultUrl, tenantId, clientId and clientSecret. The two Transport = transport assignments are deliberate: one routes token acquisition and the other routes Key Vault secrets requests.

Keep vaultUrl as the actual vault endpoint. The handler's WebProxy holds the intermediary, with public HTTP candidates available in the HTTP proxy list when the vault's network policy permits that route; configure its Credentials before constructing the clients if the network requires them.

Reuse the transport for the clients' workload and dispose owned resources at shutdown. A successful proxy connection establishes a route, while Key Vault network and access policies still decide whether the application may read the secret.

Related articles