Ayuda de Net Tinker

En esta página

Tipos de regla
Mock vs. passthrough modificado
Usar variables
Entornos
Por qué una regla puede no estar aplicándose
Cosas que parecen fallos y no lo son
Crear reglas a partir de tráfico real
Qué cubre (y qué no) "sanitizar al exportar"

Tipos de regla

Cada regla tiene exactamente un tipo, que decide qué ocurre cuando coincide con una petición:

Tipo	Qué hace	Cuándo usarlo
Mock de respuesta	La petición no llega a la red. Tú defines el status, los headers y el body.	El endpoint todavía no existe, o necesitas un caso concreto (500, lista vacía, datos malformados) difícil de provocar de verdad.
Modificar body de la petición	La petición sale de verdad, pero con un body distinto al que envió la página.	Probar cómo reacciona el backend a un payload que la interfaz normalmente no enviaría.
Modificar headers	Añade, sobrescribe o quita headers de petición y/o respuesta. La petición sale de verdad.	Forzar un header de feature flag, probar un header CORS que falta o sobra, simular un header de auth en local.
Redirigir	Envía la petición a otra URL completamente distinta.	Apuntar una llamada a un servidor local o a otro entorno sin tocar la configuración de la app.
Cancelar	La petición falla directamente — `fetch` se rechaza, XHR dispara un evento de error.	Probar qué hace tu interfaz cuando una llamada falla o un script no carga.
Modificar query params	Añade o quita parámetros de la query string. La petición sale de verdad.	Forzar un parámetro que la interfaz no expone (un flag de debug, un tamaño de página).
Reemplazar en la URL	Sustituye parte de la URL con una expresión regular, manteniendo el resto igual. La petición sale de verdad.	Cambiar `staging` por `production` en una URL sin montar una redirección completa.
Retrasar	Retiene la petición real un número fijo de milisegundos antes de dejarla pasar.	Comprobar que tus estados de carga y spinners aparecen de verdad.
Body de la respuesta	La petición sale de verdad; al body de la respuesta real se le aplica un buscar/reemplazar o se le sobrescribe un campo JSON concreto antes de que tu código lo vea.	Cambiar un campo de una respuesta real de la API (p. ej. un status) sin escribir un mock completo a mano.

Mock vs. passthrough modificado

Es la confusión más habitual, así que merece explicarse aparte:

Mock — la petición nunca sale del navegador. Net Tinker construye un Response falso (o simula las propiedades del XHR) y lo devuelve directamente. El servidor real nunca llega a verla.

Passthrough modificado (body de la petición, headers, query params, reemplazo en la URL) — la petición sale de verdad por la red, solo que no exactamente como la construyó la página. El servidor real la ve, y su respuesta real vuelve (posiblemente con los headers de respuesta también modificados de vuelta, en el caso del tipo "headers").

Modificar el body de la respuesta real — la petición sale completamente igual, y solo el body que vuelve se transforma (buscar/reemplazar, o sobrescribir un campo JSON) antes de que tu código lo lea. Los bodies que no son JSON no se pueden inspeccionar para el modo "sobrescribir un campo", así que se dejan intactos en vez de fallar en silencio sin que se note.

Una forma práctica de distinguirlos mientras depuras: abre la pestaña Network de DevTools. Una petición mockeada nunca aparece ahí (no llegó a la red); una modificada-y-dejada-pasar sí, con la URL/body/headers ya reescritos.

Usar variables

Define un par nombre/valor una vez (botón "{{ }} Variables" en la página de opciones) y reutilízalo como {{nombre}} en cualquier sitio donde repetirías la misma cadena: el body de una regla, el valor de un header, una URL de redirección, el valor de un query param, o el texto de reemplazo de una regla "Reemplazar en la URL".

Define apiHost = api.staging.example.com y úsalo como https://{{apiHost}}/v2/users en una redirección. Cambias el entorno una vez, en un sitio, en vez de buscar cada regla que tenía el host viejo escrito a mano.

Un nombre que no coincide con ninguna variable definida se deja tal cual está escrito — {{typo}} aparece literalmente en la petición o respuesta, en vez de desaparecer en silencio, así que un error es evidente en vez de un misterio. Las variables no se sustituyen en los campos de matching de una regla (el patrón de URL, o una condición de header/body/iniciador) — esos comparan contra la petición real, así que una variable ahí no significaría nada.

Entornos

Un entorno (botón "🌐 Entornos", junto a Variables) es un conjunto con nombre de sobrescrituras sobre tus variables — Local, Staging, Prod, lo que necesites. Solo hace falta que sobrescriba lo que realmente cambia entre entornos; lo que no menciona conserva el valor propio de la variable.

Con apiHost = local.test como valor base, un entorno "Prod" puede sobrescribir solo apiHost = api.example.com y dejar el resto de variables tal cual.

Elige el entorno activo con el botón de estrella junto a él en la página de opciones, o desde el desplegable del popup (solo aparece cuando existe al menos un entorno). Sin entorno activo, cada variable usa simplemente su propio valor base — igual que antes de que existieran los entornos.

Por qué una regla puede no estar aplicándose

Revisa esto en orden — cubre todos los motivos por los que una regla puede fallar en silencio:

El interruptor maestro (arriba del popup o de la página de opciones) está apagado. Nada se aplica mientras lo esté.
El interruptor propio de la regla está apagado.
La regla pertenece a un grupo desactivado. Un grupo desactivado apaga en silencio todas las reglas de dentro — el listado muestra un ⚠ junto a las reglas afectadas.
La regla está fijada a una pestaña concreta (📌) y estás probando desde otra.
El método HTTP de la petición no coincide con el configurado en la regla (si no está en "Cualquiera").
El patrón de URL/host no coincide de verdad. Si el tipo de match es Regex, una errata que deja el patrón inválido hace que la regla no coincida con nada en vez de dar un error — revisa que no le falten corchetes o tenga otro fallo de sintaxis.
La regla tiene una condición de header, de body o de dominio iniciador y la petición actual no la cumple. Para condiciones de header y de body en peticiones XHR en concreto: una regla de redirección/query params/reemplazo en la URL nunca puede activarse por ninguna de las dos, porque la URL se decide antes de que la página haya puesto sus headers o haya llamado a send(body) — esto solo funciona para los tipos "mock", "cancelar", "retrasar", "modificar body" y "modificar headers" en XHR (en fetch funciona para todos los tipos). Una condición de body además solo compara contenido de texto (JSON, form-encoded, texto plano) — los bodies FormData/Blob/binarios nunca se leen para esto.
La petición no es fetch ni XMLHttpRequest. Net Tinker solo puede interceptar esas dos — no puede afectar a <img>, <script src>, CSS, fuentes ni ningún otro tipo de recurso a la hora de aplicar una regla (el panel de captura de DevTools sí puede verlos todos, simplemente no puede actuar sobre ellos).
Otra regla anterior en la lista coincidió primero. Gana la primera regla que coincide — reordena las reglas si dos de ellas podrían aplicar a la misma petición.

Cosas que parecen fallos y no lo son

Net Tinker funciona parcheando fetch/XMLHttpRequest dentro del propio JavaScript de la página. Ese enfoque trae algunos efectos secundarios inevitables:

Añadir un header de petición puede provocar un error de CORS. Si el header añadido no está permitido por la política CORS del servidor en una llamada cross-origin, el navegador bloquea la petición — esto ocurre en la capa CORS del propio navegador, por debajo de lo que Net Tinker puede controlar.
Los headers de respuesta que añade una regla no aparecen en la pestaña Network de DevTools. Esa pestaña muestra los bytes reales que llegaron por la red; los cambios del lado de respuesta de una regla "modificar headers" se aplican después, solo sobre el objeto que lee el JavaScript de la página. Son reales para la página — solo invisibles para esa vista concreta de DevTools.
La columna "Iniciador" de DevTools muestra interceptor.js en todas las peticiones mientras haya alguna regla activa en la página, porque todas las peticiones pasan por el fetch/XMLHttpRequest parcheado de Net Tinker antes de llegar (o no) a la red. No afecta al funcionamiento, solo a la atribución. Si te molesta, añade interceptor.js a la Ignore List de DevTools (Settings → Ignore List) — así DevTools ignora esos frames al calcular el iniciador.

Crear reglas a partir de tráfico real

Abre DevTools en cualquier página y busca la pestaña "Net Tinker" (junto a Elements, Console, Network, etc.). Lista todas las peticiones que hace la página mientras el panel está abierto — no solo fetch/XHR, todos los tipos de recurso — para que encuentres exactamente la llamada que te interesa.

Cada fila tiene un desplegable con los tipos de regla y un botón dedicado Mockear. Elegir un tipo abre el editor de reglas ya relleno con la URL y el método reales de esa petición.
Mockear va más allá: también copia el código de estado, los headers de respuesta y el body reales de esa petición a la nueva regla, así partes de lo que devolvió el servidor de verdad en vez de escribir un fixture a mano.
Una marca ⚡ junto a una fila significa que alguna de tus reglas activas ahora mismo interceptaría esa petición exacta — se evalúa en vivo contra tus reglas actuales, no contra las que hubiera activas cuando la petición ocurrió de verdad.
Cada fila también tiene una opción "Copiar como…" para copiar la petición como comando curl o como fragmento fetch(), listo para pegar en una terminal o en la consola.
Para una petición GraphQL (detectada automáticamente y mostrada como su nombre de operación junto a la URL), crear una regla desde ella también rellena una condición de body exigiendo ese nombre de operación — porque un endpoint GraphQL sirve todas sus operaciones en la misma URL, y una regla que solo mirase la URL aplicaría a todas ellas. Puedes verlo y editarlo en la regla que se abre (es la misma condición de body de arriba, ya rellena por ti).

Las capturas de este panel viven solo en memoria mientras DevTools está abierto — al cerrar DevTools se vacían, y no se guarda nada hasta que conviertes explícitamente una petición capturada en una regla.

Qué cubre (y qué no) "sanitizar al exportar"

Al exportar reglas para compartir una configuración, la opción "sanitizar" revisa nombres de headers, nombres de parámetros de query y nombres de campos del body JSON (de forma recursiva) buscando algo que parezca una credencial — nombres que contengan palabras como auth, token, secret, password, apikey, credential, signature, cookie o session — y sustituye su valor por __REDACTED__.

Deliberadamente no toca:

Bodies que no son JSON (texto plano, XML, form-encoded, etc.) — no hay forma fiable de distinguir un token de texto normal en un formato arbitrario, y adivinar mal corrompería el body en silencio. Solo se revisan los bodies que se pueden parsear como JSON.
Un valor bajo un nombre de campo que no parece sensible — un token guardado bajo un campo literalmente llamado value o data no se detectaría, porque la comprobación se basa en el nombre, no en el contenido.
Booleanos, o los literales "true"/"false", aunque estén bajo un nombre que parezca sensible — access-control-allow-credentials: true no es un secreto, es un flag CORS fijo, y redactarlo solo produciría una regla rota.
El nombre, la descripción y las etiquetas de la propia regla — eso lo escribes tú, así que no se revisa.

Trata "sanitizar al exportar" como una red de seguridad contra la fuga accidental más común, no como una garantía de que el fichero exportado no contiene ningún secreto — revisa lo que vas a compartir antes de enviarlo.