Constructor
Todos los campos son opcionales. El método de la petición es indiferente y el cuerpo se ignora: todos los parámetros viajan en la cadena de consulta.
Vista previa de la URL en vivo
Se reconstruye mientras editas. Es la URL exacta que llamas.
https://arttron.dev/api/fail?status=500&rate=1Respuesta
Rellena el constructor y envía una petición para ver el estado, las cabeceras, el cuerpo y el tiempo transcurrido.
Ejemplos con un clic
Llámalo desde tu código
curl -i 'https://arttron.dev/api/fail?status=500&rate=1'const res = await fetch('https://arttron.dev/api/fail?status=500&rate=1');
console.log(res.status, await res.text());import axios from 'axios';
try {
const res = await axios.get('https://arttron.dev/api/fail?status=500&rate=1');
console.log(res.status, res.data);
} catch (err) {
console.log(err.response?.status, err.response?.data);
}¿Qué es un simulador de errores HTTP?
Un simulador de errores HTTP responde a una petición con una respuesta deliberadamente errónea para que puedas ejercitar la ruta de fallo de un cliente. En lugar de desconectar un servicio o esperar una caída real, pides un estado exacto —por ejemplo 503 o 429— y la herramienta lo devuelve. Apunta tu código a la URL del simulador y observa cómo se comporta. Esta página es la interfaz de navegador del endpoint /api/fail: el mismo motor que impulsa la herramienta MCP simulate_http_error.
Los fallos reales rara vez son un único 500. Una API inestable falla solo a veces, un límite de tasa devuelve un Retry-After, un proveedor imprime su propia forma de error (OpenAI, Stripe, AWS XML, Cloudflare), una pasarela se atasca antes de agotar el tiempo y una conexión puede simplemente cortarse. El simulador reproduce cada caso: una tasa de error de 0 a 1, un retardo fijo o aleatorio, una secuencia por clave para pruebas de reintento, una sobrescritura de Retry-After, cuerpos con forma de proveedor en JSON, text, HTML o XML, una conexión cortada y una respuesta colgada. Una semilla hace reproducibles el estado y el retardo aleatorios.
Cómo usar el simulador de errores HTTP
- Fija el estado (o una lista separada por comas de la que se elige al azar) y, si quieres fallos intermitentes, una tasa de error por debajo de 1.
- Añade según haga falta un retardo, una secuencia con clave de escenario, una sobrescritura de Retry-After, un preajuste de proveedor y un formato de cuerpo.
- Copia la URL en vivo en curl, fetch o axios, o pulsa «Enviar» para llamarla aquí mismo y leer el estado, las cabeceras, el cuerpo y el tiempo transcurrido.
- Cambia a uno de los ejemplos de un clic (API inestable, límite de tasa, reintento, lento, corte) para obtener un fallo realista de un solo movimiento.
Preguntas frecuentes sobre el simulador de errores HTTP
¿Por qué un corte de conexión no es una desconexión real?
El App Router de Next.js no expone una API de socket sin procesar, así que un socket.destroy real no está disponible. La ruta envía la cabeza de la respuesta y luego aborta el flujo del cuerpo, de modo que los clientes observan un error de red (terminated / fetch failed) en lugar de un estado limpio. La respuesta lleva X-Sim-Drop: true para que la emulación sea explícita.
¿Cómo funciona el modo secuencia?
Con seq y una clave, la n-ésima petición para esa clave recibe el n-ésimo código de la lista y luego la secuencia se repite. El contador vive por clave durante una hora y se renueva en cada acierto, así que una prueba de reintentos conserva su orden durante toda la ejecución.
¿Es gratis y necesita clave?
La interfaz web llama a /api/fail sin clave. Los scripts pueden autenticarse con una clave de API; el endpoint está limitado a 60 peticiones por minuto por IP.
