ErrorBase
Referencia técnica independienteSitio oficial
  • Software y sistemas
  • Servicio HTTP

416

HTTP 416 Range Not Satisfiable: rango pedido fuera del recurso

Verificada con fuentes2 fuentesRevisada 4 oct 2026
¿Viene un técnico? Mira los 2 pasos que debe enseñarte

Nivel de riesgo

Seguro

Puedes actuar sin peligro siguiendo las comprobaciones seguras.

Urgencia

Media — atiéndelo hoy

Respuesta rápida

El servidor rechaza la cabecera Range: ningún rango pedido cabe en el recurso actual o se pidieron demasiados rangos pequeños o solapados. Comprueba el rango frente a la longitud que indica Content-Range y repite la descarga sin Range.

Seguridad primero

Antes de continuar

  • No unas trozos de un archivo sin comprobar que todos vienen de la misma versión del recurso: usa If-Range o vuelve a descargarlo completo.

Puedes hacerlo con seguridad

  • Petición y respuesta exactas
  • Número y orden de los rangos
  • Cambio del recurso y If-Range
  • Descarga desde cero sin Range

Deja estas tareas a un profesional cualificado

  • No intentes esta tarea profesional: Revisión del servidor, proxy o CDN
  • No intentes esta tarea profesional: Corrección del cálculo de rangos en el cliente

Lo que un técnico debe poder justificar

Viene un técnico

Estos son los pasos que tiene que hacer y enseñarte. Márcalos mientras trabaja: si se salta pasos, no aceptes el cambio de pieza.

No son instrucciones para que abras o manipules el equipo. Son las comprobaciones que deben sostener una conclusión técnica.

  1. Revisión del servidor, proxy o CDN

    Qué haceSi un rango válido recibe 416, el administrador del alojamiento o de la CDN revisa la política de rangos de cada salto.

    Te tiene que enseñaren qué salto se genera el 416 y su Content-Range.

    Por escritola regla aplicada y por qué.

  2. Corrección del cálculo de rangos en el cliente

    Qué haceEl desarrollador del cliente o del gestor de descargas corrige cómo calcula Range y añade If-Range al reanudar.

    Te tiene que enseñaruna petición con Range válido y la respuesta 206 correcta.

    Por escritoel cambio hecho y la versión que lo incluye.

Antes de aceptar una pieza o reparación

Aún no ha demostrado nada. No aceptes un cambio de pieza solo por el código.

Sigue estos pasos

Aviso: Sigue el orden documentado. Un código identifica el sistema afectado, pero por sí solo no demuestra qué pieza está averiada.

  1. Petición y respuesta exactas

    Sin herramientas especiales

    Quién:
    desarrollador o administrador del sitio, con las herramientas de red del navegador o un cliente HTTP.
    Cómo:
    captura la cabecera Range enviada y las cabeceras de la respuesta 416, en especial Content-Range.
    Resultado que importa:
    la longitud actual que indica Content-Range (bytes */longitud).
    Si la primera posición pedida es mayor o igual que esa longitud:
    confirma un rango fuera del recurso.
    Si el rango cabe en la longitud:
    apunta a rangos múltiples o a una política del servidor o del proxy.
    Evidencia a conservar:
    petición y respuesta guardadas, sin cookies ni tokens.

    Evidencia: RFC 9110 - HTTP Semantics

  2. Número y orden de los rangos

    Sin herramientas especiales

    Quién:
    desarrollador del cliente.
    Cómo:
    cuenta cuántos rangos lleva la cabecera Range y si se solapan o no van en orden ascendente.
    Resultado que importa:
    si la petición pide muchos tramos pequeños o solapados.
    Si los pide:
    indica la causa que RFC 9110 permite rechazar; pide un único rango que los englobe.
    Si es un solo rango:
    descarta esta causa.
    Evidencia a conservar:
    cabecera Range completa.

    Evidencia: RFC 9110 - HTTP Semantics

  3. Cambio del recurso y If-Range

    Sin herramientas especiales

    Quién:
    desarrollador del cliente o del gestor de descargas.
    Cómo:
    comprueba si el cliente envía If-Range con el ETag o la fecha de la copia parcial.
    Resultado que importa:
    si la reanudación valida que el recurso no ha cambiado.
    Si no envía If-Range y el recurso cambió:
    confirma que el rango antiguo no cabe en la versión nueva.
    Si lo envía:
    con el recurso cambiado el servidor debería mandar el recurso entero, no un 416.
    Evidencia a conservar:
    ETag o fecha de la copia y del recurso actual.

    Evidencia: RFC 9110 - HTTP Semantics

  4. Descarga desde cero sin Range

    Sin herramientas especiales

    Quién:
    tú, si el error sale al reanudar una descarga.
    Cómo:
    borra la descarga parcial y empieza de nuevo desde el principio.
    Resultado que importa:
    si la descarga completa funciona.
    Si funciona:
    confirma que el problema era el rango de la copia parcial.
    Si también falla:
    indica un problema del servidor que debe revisar quien lo administra.
    Evidencia a conservar:
    hora y enlace de la descarga, sin datos personales.

    Evidencia: RFC 9110 - HTTP Semantics

Situación no resuelta

Si el error persiste, no sigas probando por tu cuenta. Mira qué tiene que hacer y enseñarte el técnico.

Dónde se aplica este código

Un código solo tiene significado dentro del producto y la versión correctos.

Ámbito principal

Sistema
Software y sistemas
Marca
HTTP
Tipo de producto
Servicio HTTP

Variantes conocidas del código

  • 416 Bereich nicht erfüllbar
  • 416 Intervallo non soddisfacibile
  • 416 Plage non satisfaisable
  • 416 Range Not Satisfiable
  • 416 Rango no satisfacible
  • événement Fronius 416
  • evento Fronius 416
  • Fronius Ereignis 416
  • Fronius event 416
  • Fronius inverter 416
  • Fronius Symo / Eco 416
  • Fronius Wechselrichter 416
  • HTTP 416
  • HTTP status 416
  • inversor Fronius 416
  • inverter Fronius 416
  • onduleur Fronius 416

Qué significa

RFC 9110 define 416 (Range Not Satisfiable): el servidor rechaza el conjunto de rangos de la cabecera Range porque ninguno es satisfacible o porque el cliente pidió un número excesivo de rangos pequeños o solapados. En bytes, un rango es satisfacible si su primera posición es menor que la longitud actual del recurso. El servidor debería enviar Content-Range con esa longitud (por ejemplo bytes */47022). El código señala una discrepancia entre la petición y el recurso, no una avería del servidor.

Advertencias y condiciones de parada

  • Seguroadvertencia editorial

    No unas trozos de un archivo sin comprobar que todos vienen de la misma versión del recurso: usa If-Range o vuelve a descargarlo completo.

    Evidencia: RFC 9110 - HTTP Semantics

Síntomas y causas

Causas probables · en orden

  • Rango que empieza después del final del recursoFrecuente

    La primera posición pedida es igual o mayor que la longitud actual; se ve al comparar Range con la longitud de Content-Range.

    Evidencia: RFC 9110 - HTTP Semantics

  • Recurso cambiado desde la descarga parcialPosible

    El cliente reanuda una copia parcial de una versión anterior más larga; sin If-Range, el rango antiguo ya no cabe en la versión actual.

    Evidencia: RFC 9110 - HTTP Semantics

  • Demasiados rangos pequeños o solapadosPosible

    RFC 9110 permite rechazarlos como posible ataque de denegación de servicio; se distingue porque la cabecera Range lista muchos tramos.

    Evidencia: RFC 9110 - HTTP Semantics

Técnico virtual

¿Sigue apareciendo 416 tras comprobarlo?

Responde unas preguntas para acotar la causa probable y la siguiente acción segura. Es una orientación - nunca sustituye a un profesional.

Iniciar diagnóstico

Fuentes y referencias técnicas

  1. 1

    IANA HTTP Status Code Registry

    Internet Assigned Numbers Authority · 2025 · standard

  2. 2

    RFC 9110 - HTTP Semantics

    IETF / RFC Editor · 2022 · standard

Fuentes: IANA HTTP Status Code Registry · RFC 9110 - HTTP Semanticsrevisado 2026-10-04 · verificado

¿Te ha resultado útil esta ficha?