Un cliente de servicio generado puede tener tanto un extremo de servicio como configuración de enlace relacionada con el proxy. Empiece por identificar qué dirección corresponde a qué función. El servicio SOAP sigue siendo el destino; ProxyAddress nombra a un intermediario.

En BasicHttpBinding, UseDefaultWebProxy selecciona el comportamiento de proxy configurado automáticamente y su valor predeterminado es true. El contrato de Microsoft no admite combinar ese valor true con un ProxyAddress explícito no nulo. Haga la elección coherente en lugar de asignar ambos y suponer que uno gana en silencio. Para un servicio SOAP accesible públicamente en una ruta de proxy pública no autenticada permitida, la lista de proxies HTTP proporciona direcciones candidatas para ProxyAddress; no conserve credenciales de proxy de otro extremo.

Compruebe el enlace que realmente usa el extremo

Un asistente puede construir el enlace correcto mientras el cliente generado sigue usando otro extremo configurado. Inspeccione el enlace asignado a la llamada que falla. Cambiar una entrada de configuración que el cliente nunca seleccionó no puede afectar a su ruta.

Después distinga el tipo de credencial de proxy del tipo de credencial de servicio. Una contraseña que exige el servicio SOAP no es automáticamente una cuenta para el intermediario de red seleccionado.

El modo de seguridad del transporte es otra decisión. Cambiar a un modo solo de credenciales solo porque una respuesta antigua lo sugiere cambia los supuestos de transporte; no demuestra que la ruta o la cuenta sean correctas. Conserve el TLS de destino previsto y use la disposición de autenticación que admiten el cliente WCF implementado y el proxy.

Un diagnóstico útil nombra el extremo de servicio, el origen de proxy seleccionado, la instancia de enlace y la primera etapa de la respuesta. Eso acota un 407 sin convertir un cliente de servicio generado en una colección de conjeturas de configuración sin relación.

Artículos relacionados