WCF BasicHttpBinding: ProxyAddress and UseDefaultWebProxy

A generated service client can have both a service endpoint and proxy-related binding settings. Start by identifying which address belongs to which role. The SOAP service remains the destination; ProxyAddress names an intermediary.

For BasicHttpBinding, UseDefaultWebProxy selects the auto-configured proxy behavior and defaults to true. Microsoft's contract does not support combining that true value with a non-null explicit ProxyAddress. Make the choice coherent rather than assigning both and assuming one silently wins. For a publicly reachable SOAP service on an allowed unauthenticated public-proxy route, the HTTP proxy list provides candidate addresses for ProxyAddress; retain no proxy credentials from another endpoint.

Check the binding actually used by the endpoint

A helper can construct the correct binding while the generated client still uses another configured endpoint. Inspect the binding assigned to the failing call. Changing a configuration entry that the client never selected cannot affect its route.

Then distinguish proxy credential type from service credential type. A password required by the SOAP service is not automatically an account for the selected network intermediary.

Transport security mode is another decision. Switching to a credential-only mode merely because an old answer suggests it changes transport assumptions; it does not prove the route or account is correct. Preserve the intended destination TLS and use the authentication arrangement supported by the deployed WCF client and proxy.

A useful diagnostic names the service endpoint, selected proxy source, binding instance and first response stage. That narrows a 407 without turning a generated service client into a collection of unrelated configuration guesses.