Check whether the Tables builder receives a complete HTTP pipeline. That input overrides its separate httpClient option; if the application owns a pipeline, configure the proxy-aware transport while constructing that pipeline.

For the direct Netty HTTP-client input, build the transport and pass it to Tables:

ProxyOptions proxy = new ProxyOptions(
    ProxyOptions.Type.HTTP,
    new InetSocketAddress("proxy.example.net", 8080)
);
proxy.setCredentials(proxyUser, proxyPassword);

HttpClient transport = new NettyAsyncHttpClientBuilder()
    .proxy(proxy)
    .build();

TableClient tables = new TableClientBuilder()
    .connectionString(storageConnectionString)
    .tableName("records")
    .httpClient(transport)
    .buildClient();

HttpClient here is com.azure.core.http.HttpClient. The other types come from Azure Core HTTP/Netty, Azure Data Tables and java.net.InetSocketAddress. The application supplies the configuration and credential variables.

ProxyOptions.Type.HTTP selects the intermediary; setCredentials supplies its account and can be omitted for no-auth endpoints. In that configuration, an HTTP proxy list entry can supply the address for an allowed public Tables endpoint route; leave no proxy credentials on the transport. The storage connection string still chooses the Tables service.

This uses connection-string authentication. An identity-credential arrangement can have a separate token-acquisition HTTP client, whose route needs to be configured as well.

Related articles