TL;DR: El error «La conexión subyacente se cerró: ocurrió un error inesperado en un envío» aparece al actualizar consultas en Power BI Desktop y casi siempre es un problema de red o protocolo, no de tus datos. Las causas más comunes son IPv6 mal negociado en el adaptador WiFi, TLS 1.2 deshabilitado, un proxy o VPN que corta la conexión, o un timeout en consultas largas. El arreglo más rápido y reportado es desactivar IPv6 en el adaptador de red; si no, fuerza TLS 1.2. Este error acumula más de 164 000 vistas en el foro oficial de Power BI.
¿Por qué aparece «La conexión subyacente se cerró» en Power BI?
Aparece porque el cliente de Power BI (la pila .NET que ejecuta Power Query) inicia una conexión segura con la fuente y esta se corta antes de completar el envío. El mensaje completo suele ser «The underlying connection was closed: An unexpected error occurred on a send». No indica un dato corrupto: señala que el canal de red o el handshake de seguridad falló a mitad de camino.
Las causas se concentran en cuatro frentes: la negociación IPv6/IPv4 del adaptador, la versión de TLS que tu equipo ofrece (las fuentes modernas rechazan TLS 1.0/1.1), la intermediación de proxy, VPN o firewall, y los timeouts en consultas que tardan demasiado. Un detalle clave del caso más citado en el foro: el usuario solo veía el error con su WiFi de casa, no con el hotspot del móvil ni con cable. Eso descarta tus datos y apunta directo a la red o al adaptador, que es donde conviene empezar a diagnosticar.
Diagnóstico rápido: ¿es tu red, tu equipo o la fuente?
Antes de tocar configuraciones, aísla el origen cambiando una sola variable a la vez. Si el error desaparece al cambiar de red, el problema es de red o adaptador; si persiste en todas, es de protocolo (TLS) o de la fuente. Este descarte de 5 minutos evita horas de cambios a ciegas.
Haz estas pruebas en orden:
- Cambia de red: conéctate por cable o comparte datos desde el móvil (hotspot). Si funciona, el problema está en tu WiFi/adaptador → ve a la Solución 1.
- Prueba otra fuente: actualiza una consulta a un origen distinto (un Excel local). Si esa sí actualiza, la fuente original o su TLS es el problema.
- Compara Desktop vs Service: si falla en Power BI Desktop pero el refresco en la nube funciona, el problema es local de tu máquina, no de la fuente.
En el caso original del foro, el paso 1 fue decisivo: con hotspot móvil no había error, con WiFi de casa sí, pese a tener la misma velocidad. Eso llevó directo al adaptador de red.
Solución 1: Desactivar IPv6 en el adaptador de red
Esta es la solución aceptada en el hilo con más de 164 000 vistas: cuando el adaptador negocia mal IPv6, la conexión segura se cae en el envío. Desactivar IPv6 en la tarjeta WiFi fuerza IPv4 y restablece la estabilidad. Es reversible y no afecta el uso normal de internet en la mayoría de redes domésticas.
Pasos en Windows:
- Panel de control → Redes e Internet → Centro de redes y recursos compartidos.
- Clic en Cambiar configuración del adaptador.
- Doble clic en tu adaptador WiFi.
- En la pestaña General, clic en Propiedades.
- Desmarca la casilla Protocolo de Internet versión 6 (TCP/IPv6).
- Clic en Aceptar y reinicia Power BI Desktop.
Si el error desaparece, ya tienes la causa. Si vuelve más adelante, combina esta solución con forzar TLS 1.2 (Solución 2).
Solución 2: Forzar TLS 1.2 en Power BI
Muchas fuentes (SharePoint Online, APIs, SQL en la nube) ya rechazan TLS 1.0 y 1.1; si tu .NET no ofrece TLS 1.2, el servidor cierra la conexión y obtienes este error. Forzar TLS 1.2 a nivel de sistema soluciona los casos que no son de red local. Se hace tocando el registro de Windows para la pila .NET que usa Power BI.
Crea un archivo .reg con este contenido y ejecútalo (requiere reiniciar el equipo):
Windows Registry Editor Version 5.00
[HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\.NETFramework\v4.0.30319]
"SchUseStrongCrypto"=dword:00000001
[HKEY_LOCAL_MACHINE\SOFTWARE\WOW6432Node\Microsoft\.NETFramework\v4.0.30319]
"SchUseStrongCrypto"=dword:00000001SchUseStrongCrypto obliga a las aplicaciones .NET (incluido Power BI Desktop) a usar TLS 1.2 en lugar de protocolos viejos. Tras reiniciar, vuelve a actualizar la consulta. Esta es la causa más frecuente cuando el error ocurre en todas las redes, no solo en una. La guía oficial de solución de problemas de actualización de Microsoft Learn detalla otros escenarios de fallo relacionados.
Solución 3: Revisar proxy, VPN y firewall
Un proxy corporativo, una VPN o un firewall pueden inspeccionar y cortar la conexión TLS a mitad del envío, sobre todo con fuentes en la nube. Si el error solo aparece dentro de la red de la empresa o con la VPN activa, el intermediario es el sospechoso. La prueba más rápida es desconectar la VPN y reintentar.
Acciones recomendadas:
- Desactiva temporalmente la VPN y actualiza la consulta; si funciona, pide a TI excluir los dominios de la fuente.
- Revisa el proxy en Opciones de Power BI → Configuración de la fuente de datos; un proxy mal configurado bloquea el handshake.
- Lista blanca de dominios: pide a TI permitir los endpoints de tu fuente (por ejemplo,
*.sharepoint.como el host de tu SQL en la nube) en el firewall.
Cuando el problema es corporativo, la solución casi siempre pasa por TI; documenta en qué red falla y en cuál no para acelerar el ticket.
Solución 4: Ajustar el timeout en consultas largas
Si la consulta tarda mucho (tablas enormes, APIs lentas), la conexión puede cerrarse por tiempo de espera y devolver este mismo error. Aumentar el CommandTimeout en el conector da margen para que la fuente responda. Se hace editando el paso de origen en el editor avanzado de Power Query.
Para SQL Server, añade el parámetro de timeout al conector:
let
Origen = Sql.Database(
"miservidor",
"mibase",
[CommandTimeout = #duration(0, 1, 0, 0)] // 1 hora
)
in
Origen#duration(0, 1, 0, 0) fija una hora de espera (días, horas, minutos, segundos). Para fuentes web, Web.Contents admite Timeout = #duration(...) de forma análoga. Si el error desaparece al subir el timeout, la causa era la duración de la consulta, no la red.
Cómo prevenir que vuelva a ocurrir
La prevención combina mantener TLS 1.2 activo de forma permanente, estandarizar la red de trabajo y vigilar la duración de las consultas. La mayoría de reapariciones se deben a actualizaciones de Windows que revierten ajustes o a cambios de red.
Buenas prácticas:
- Deja
SchUseStrongCryptoaplicado para que TLS 1.2 sobreviva a reinicios. - Trabaja por cable cuando actualices modelos grandes, más estable que el WiFi.
- Optimiza las consultas pesadas (filtra en origen, usa plegado de consultas) para no rozar el timeout.
- Documenta el arreglo que funcionó en tu equipo; es la referencia más rápida si reaparece.
Si trabajas a diario con fuentes externas, conviene dominar el conector y el lenguaje M para diagnosticar estos cortes; el artículo de errores DataFormat.Error en Power Query complementa esta guía con otra familia de fallos de actualización.
Preguntas frecuentes
¿Por qué el error solo ocurre en mi WiFi de casa y no con el móvil? Porque tu adaptador WiFi negocia mal IPv6 en esa red concreta. Con el hotspot del móvil la negociación es distinta y no falla. La solución es desactivar IPv6 en el adaptador (Solución 1), no cambiar de proveedor.
¿Afecta a Power BI Desktop, al Service o a ambos? Suele aparecer en Power BI Desktop al refrescar localmente. Si el refresco en el Service funciona pero en Desktop no, el problema es de tu máquina (red, TLS o adaptador), no de la fuente ni del modelo.
¿Desactivar IPv6 es seguro? Sí, en redes domésticas normales no notarás diferencia: el equipo seguirá navegando por IPv4. Es un cambio reversible; si algo falla, vuelve a marcar la casilla.
¿Y si ninguna solución funciona? Revisa si un antivirus o una herramienta de inspección SSL está interceptando la conexión, y prueba en otra cuenta de Windows. Si persiste con TLS 1.2 forzado y sin VPN, abre un ticket con Microsoft adjuntando en qué redes falla.
Conclusión
«La conexión subyacente se cerró» en Power BI es, en el 90 % de los casos, un problema de red o de protocolo, no de tus datos. Empieza por el diagnóstico de red (cambia de WiFi a cable o hotspot), aplica la desactivación de IPv6 si el error depende de la red, y fuerza TLS 1.2 si ocurre en todas partes. Proxy, VPN y timeouts cubren el resto de escenarios.
Si quieres trabajar con confianza fuentes externas —SharePoint, SQL, APIs— y dominar el conector y el lenguaje M que hay detrás de cada actualización, este curso te da las bases:
Deja una respuesta