Por Qué tu WMS No Carga en el Navegador

Pegaste una URL de WMS que funciona. Funciona en QGIS. No funciona en tu mapa web, y el error es directamente nada o una frase que suena a que el servidor está caído cuando claramente no lo está.

Cada uno de estos casos tiene una causa aburrida y específica. Este post los recorre en el orden en que un navegador los encuentra, usando los mensajes que muestra nuestro propio visor WMS / WMTS: uno por cada falla, no un único "no se pudo cargar".

Primero, abrí la URL de capabilities en una pestaña de navegador común: XML significa que el host es alcanzable y el problema está en la respuesta, o es CORS; una página de error o nada significa que el problema está en el pedido.

Contenido mixto: el servicio habla HTTP simple y tu página no

El síntoma aparece antes de que salga cualquier pedido: Este servicio solo responde por http://, y tu navegador bloquea eso en esta página segura — incluidos los tiles del mapa. Ningún proxy puede arreglar esto por ti; quien opera el servicio debe habilitar HTTPS.

Una página segura no puede traer subrecursos por un esquema inseguro, y los tiles también son subrecursos — así que ni siquiera una lista de capas ya obtenida ayudaría: cada GetMap queda bloqueado de la misma manera (contenido mixto).

• Probá la dirección segura. Muchos servicios responden en los dos esquemas y publican solo el inseguro; el visor lo ofrece al lado del error, con la etiqueta Probar la dirección https://.
• Poné un proxy en tu propio servidor. La única solución real cuando el servicio no tiene ningún endpoint seguro.
• Pedile al operador que habilite TLS. Lento, pero ayuda a todos los que vengan después de vos.

CORS: el pedido salió, y el navegador tiró la respuesta a la basura

Este es de los que te cuestan una tarde entera, porque cualquier herramienta a la que recurras te dice que el servidor está bien. El síntoma es una falla sin código de estado, y tiene dos variantes. Si el host es alcanzable: Este servidor está en línea, pero no permite solicitudes de origen cruzado desde un navegador (CORS), así que su lista de capas no se puede leer aquí — los tiles podrían seguir funcionando. Geodocs lee servicios así a través de su propio servidor. Si no lo es: No pudimos contactar a este servidor en absoluto — puede estar fuera de línea, inalcanzable, o la dirección puede ser incorrecta.

La causa: el pedido salió, el servidor respondió, y como la respuesta no traía un header access-control-allow-origin que nombrara tu origen, el navegador la descartó antes de que tu código viera un solo byte. Es una regla del navegador sobre qué puede leer una página, así que, según el propio servidor, no pasó nada malo (CORS en MDN).

Por eso el servicio funciona en QGIS y falla en tu aplicación web, y ninguno de los dos está roto. QGIS no es un navegador: no tiene origen, así que no hay nada que chequear ni nada que rechazar — lo mismo pasa con curl y con tu propio backend. "Pero funciona en QGIS" es evidencia a favor del diagnóstico de CORS, no en contra.

• Poné un servidor en el medio. Tu backend trae el documento de capabilities y los tiles, y los sirve desde tu propio origen, así que nada queda como origen cruzado.
• Conseguí que el operador mande el header. Un solo access-control-allow-origin lo arregla para todos los clientes de navegador que vayan a tener.

El servidor respondió con un código de error

El síntoma trae el número: El servidor respondió con un error ({status}). Revisa la dirección e inténtalo de nuevo. — el placeholder lleva el estado real. La causa suele estar en la dirección:

• Un segmento de ruta que no es el servicio. Los portales publican una landing page y un endpoint que difieren en un solo elemento; la landing page devuelve 404.
• Falta el query string. Algunos servidores necesitan que escribas SERVICE=WMS&REQUEST=GetCapabilities explícitamente, y responden 400 en vez de redirigir.
• Un 403 que tiene que ver con tu cliente, no con tu pedido — mirá la sección sobre user-agent más abajo.
• Un 500 en la versión que pediste. Sacar VERSION=1.3.0, o ponerla en 1.1.1, cambia la respuesta en más servidores de los que debería.

Leé el cuerpo, no el número: HTML significa que te está hablando un portal, XML significa que te está hablando el servicio, y el XML nombra el parámetro que no le gustó.

Respondió, pero no con XML — o no con capabilities

Dos síntomas vecinos, una sola causa. Si el cuerpo no se puede parsear como XML: Esa dirección respondió, pero no con un documento XML válido. Si se parsea pero su elemento raíz no es uno que la herramienta reconozca: Esa dirección respondió, pero no con un documento de capabilities OGC.

Los dos casos suelen significar que le pediste capabilities a una página web y te devolvió una página web — un muro de login, un aviso de "temporalmente no disponible", un portal cautivo. El estado está bien; el cuerpo fue escrito para un humano.

El miembro sutil de la familia: cuando un WMS se niega a nivel OGC, responde con un ServiceExceptionReport, XML perfectamente válido cuya raíz no es una raíz de capabilities — así que el visor lo llama "no es un documento OGC" en vez de una excepción. Abrilo: te dice por qué.

Una dirección de WMTS en el cuadro de WMS

El síntoma nombra lo que encontró: Esto parece un servicio {found}, no el que seleccionaste. — en mayúsculas, como WMTS o WFS.

WMS, WMTS y WFS son tres protocolos de los que la gente habla como si fueran uno solo, y elegir mal no es un error de tipeo que se vea en la URL — por eso la herramienta lee el documento y te dice cuál es. Cambiá el selector y reconectá, pero sabé qué querés: WMS renderiza una imagen del bounding box que pediste, WMTS sirve tiles pre-renderizados en una grilla fija y es más rápido, WFS devuelve features (OGC WMS).

Tardó demasiado, o el documento era demasiado grande

Dos límites, dos frases. Por tiempo: Esto tardó más de 30 segundos en responder. Algunos documentos de capabilities pesan varios megabytes — puedes intentarlo de nuevo. Por tamaño: La respuesta del servidor era demasiado grande para cargarla con seguridad y se detuvo a la mitad. Prueba con un área más pequeña o una capa más específica.

Ninguno de los dos es arbitrario: en algunos servicios nacionales, un documento de capabilities trae decenas de miles de capas y megabytes de XML, y una pestaña que lo parsea se bloquea mientras tanto. Reintentar funciona más seguido de lo que pensás, porque estos servidores son lentos con la caché fría. Si nunca termina, la única solución es un backend que cachee el documento una vez.

Se conectó, pero la capa no se dibuja

Hay otra familia que cubre la brecha entre conectarse y renderizar. Una capa que el mapa no puede proyectar: Esta capa no tiene un sistema de coordenadas que el mapa pueda usar. Un servicio que solo ofrece formatos que no puede dibujar: Este servicio no ofrece ningún formato de imagen que el mapa pueda renderizar. Una capa WMTS sin una grilla usable: Esta capa no tiene un conjunto de matrices de teselas que el mapa pueda usar. Un id de capa que el documento no contiene: Este identificador de capa no está en las capabilities del servicio.

Estos son los casos honestos: el servicio respondió, el documento se parseó, y esta capa no declara nada con lo que el renderizador pueda trabajar. Pasa sobre todo con servicios nacionales viejos que publican un CRS proyectado local y nada de Web Mercator, y con ids de capa copiados de un documento que después cambió.

El servidor rechaza a tu cliente, no a tu pedido

Este caso produce un diagnóstico seguro y equivocado. Algunos servidores deciden qué mandarte según tu string de User-Agent, y no todos de la misma manera. Al probar dos tandas de fuentes de datos el 11 de septiembre de 2026 — dieciséis hosts de elevación y ocho hosts de rásters de muestra — aparecieron tres comportamientos distintos:

• Rechaza un Mozilla/5.0 genérico, sirve a un navegador y a curl. naturalearthdata.com responde 200 a un pedido simple de curl y rechaza con 406 a un Mozilla/5.0 genérico — una regla antibots que dispara con el token genérico, no con scripts.
• Rechaza a los dos, sirve a un navegador real. www.usgs.gov rechaza a curl y a un Mozilla/5.0 genérico con 403, y responde 200 a un string de user-agent de Chrome completo. No hay nada bloqueado de verdad; el rechazo fue un artefacto de cómo preguntamos.
• Rechaza todo lo que le pudimos apuntar. El portal del IBGE responde con una pantalla intersticial de Cloudflare a cualquier cliente que probamos, incluido un string de user-agent de Chrome completo — si un navegador real pasa es algo que ningún script puede probar desde acá.

También pasa al revés: reverificado hoy, el WMS de Digital Earth Africa responde 200 a un user-agent genérico y 403 a un string completo de Chrome, así que un cliente de escritorio anda bien y una app de navegador en Chrome o Edge queda bloqueada. Un código de estado desde un script de shell es un dato sobre ese script, no sobre el servicio.

Cómo leer un error de GetCapabilities por su elemento raíz

Cuando un pedido de capabilities sale mal, mirá el primer elemento del cuerpo. Es una clasificación de cinco vías que te dice en cuál de las secciones de arriba estás:

• WMS_Capabilities o WMT_MS_Capabilities — un documento de capabilities de WMS, 1.3.0 y 1.1.1 respectivamente. Esto es un éxito.
• Capabilities en el namespace de WMTS — un documento de capabilities de WMTS. Éxito, en el otro protocolo.
• WFS_Capabilities — un WFS. Features, no imágenes.
• ServiceExceptionReport o ExceptionReport — el servicio se negó y dice por qué. Leé el elemento de adentro; nombra el parámetro.
• html, o un DOCTYPE — una página para un humano. Un muro de login, un portal, una página de error de algo delante del servicio.

Encontrar la palabra "Exception" en el cuerpo no prueba nada. Un documento de capabilities válido legítimamente contiene un elemento Exception que lista los formatos en los que el servicio reporta errores, así que buscarla con grep es la forma en que la gente se convence de que un servicio que funciona está roto. Clasificá por el elemento raíz, nunca por un substring.

Archivos de prueba que podés usar

Estos son endpoints, no archivos — algo que sabés que funciona, para poder distinguir "mi código está mal" de "este servicio está mal". Cada línea se volvió a probar el 11 de septiembre de 2026 desde un script que manda un header Origin; un resultado de sonda es un momento de una sola dirección, por eso lleva la fecha.

• EOX Maps, WMTS — https://tiles.maps.eox.at/wmts/1.0.0/WMTSCapabilities.xml, 200, raíz Capabilities, devolviendo el origen del pedido en access-control-allow-origin. Abierto y usable desde una app de navegador; con licencia de EOX, así que revisá sus términos primero.
• terrestris OSM, WMS — https://ows.terrestris.de/osm/service?SERVICE=WMS&REQUEST=GetCapabilities&VERSION=1.3.0, 200, raíz WMS_Capabilities, access-control-allow-origin: *. Abierto; datos de OpenStreetMap bajo ODbL, así que hace falta dar atribución.
• Digital Earth Africa, WMS — 200 para un script, 403 para un user-agent completo de Chrome, hoy. Anda bien en QGIS, inusable desde una app de navegador en Chrome o Edge.
• Famoso y roto, para que dejes de buscarlo — el portal global de OneGeology está en todas las listas de "WMS gratis", y su certificado todavía no coincide con su hostname. Todos los clientes lo rechazaron hoy, y ningún proxy arregla eso.

Para más, usá la lista de servicios WMS y WMTS gratuitos — el conjunto completo, con un estado por cada entrada.

Cuando nada funciona: QGIS, ogr2ogr y los presets propios de la herramienta

Si ya pasaste por todas las secciones y sigue sin cargar, cambiá de cliente. Eso es lo que te dice de qué lado está el problema.

• Abrilo en QGIS. Pegá la URL base en una conexión nueva de WMS/WMTS. Si la lista de capas se llena, el servicio está sano y tu problema es una regla del navegador — CORS o contenido mixto, que se arregla con un servidor en el medio.
• Traelo con GDAL. El driver WMS de GDAL lee un WMS como fuente ráster desde la línea de comandos, sin origen y sin reglas de navegador en el medio; para un WFS, ogr2ogr trae las features a un archivo.
• Probá un servicio que sabés que funciona. El visor trae tres presets, cada uno verificado en un navegador real desde un origen real y no desde un script: EOX Sentinel-2 sin nubes sobre WMTS, terrestris OpenStreetMap sobre WMS, USGS topográfico sobre WMS. Si uno carga y tu URL no, la diferencia está en la URL.

Si preferís no mantener un proxy para los servicios que rompen CORS, una caché para los lentos, y una lista de cuál es cuál, eso es lo que hace Geodocs.