Ayuda de Net Tinker

Read in English

Quiero… — encontrar la herramienta adecuada

Cada nombre en negrita está escrito exactamente como aparece en la extensión, así que puedes buscarlo con Ctrl+F aquí y encontrarlo igual en la interfaz.

…cambiar lo que hace una petición o una respuesta

Todo esto es una regla. El tipo se elige en el desplegable Tipo de regla al crearla.

…moverme por la extensión

Tu primera regla: qué campos importan de verdad

Pulsa + Nueva regla (en el popup o en la página de opciones). El formulario se abre en Mockear la respuesta (API), que es el caso más común: contestar una petición desde el navegador en vez de dejar que llegue al servidor. Lo que el formulario enseña de entrada es poco —el resto va plegado en cuatro bloques, que se explican justo debajo— y casi todo es opcional. Esto es lo que necesita de verdad un mock JSON:

1. URL / patrón — el único campo sin el cual la extensión no guarda la regla. Por defecto se lee como Contiene, así que con /api/users basta para atrapar todas las URL que lleven ese fragmento. Ver Elegir con qué peticiones coincide una regla.
2. Código de estado — empieza en 200. Es una caja numérica normal con una lista de sugerencias asociada (200, 201, 204, 301, 400, 401, 403, 404, 429, 500, 502, 503…): pincha para elegir una, o escribe directamente el código que quieras.
3. Headers — una regla de mock nueva se abre con Content-Type: application/json ya escrito en la caja, como valor de verdad: puedes editarlo o borrarlo, y lo que se ve es lo que se guarda. Si lo borras, el mock vuelve como texto plano —algo perfectamente legítimo, para reproducir un servidor que no manda el tipo—, y al guardar nadie te repone la cabecera. Abrir una regla que ya existe no le añade nada, ni aunque tenga los headers vacíos.
4. Body de respuesta — lo que recibe quien llama. Los botones { } Formatear y { } Minificar de encima ordenan el JSON, y un aviso debajo te dice si lo que has escrito es JSON válido.

Todo lo demás sirve para afinar la regla o para encontrarla después, y vive en cuatro bloques plegables: Organización (descripción, etiquetas, grupo), Coincidencia avanzada (origen, tipo de match, método), Condiciones adicionales (opcional) (condiciones de header, body e iniciador) y Simulación de red (latencia y código de estado, que se aplican a cualquier tipo de regla). En una regla nueva los cuatro empiezan cerrados; al editar una que ya existe se abre cada bloque que esa regla use, así que un bloque plegado nunca esconde algo que hayas puesto. Dos cosas que conviene hacer antes de cerrar:

• Pega una URL real en URL de prueba (opcional). Te dice al momento si esta regla coincidiría con ella, sin guardar nada y sin lanzar ninguna petición.
• Guarda, recarga la página y mira el icono de la extensión en la barra: lleva un contador de reglas aplicadas en esa pestaña. Si sigue vacío, la regla no se ha aplicado nunca — vete a Por qué una regla puede no estar aplicándose.

Tipos de regla

Cada regla tiene exactamente un tipo, que decide qué ocurre cuando coincide con una petición. El nombre en negrita es el del desplegable Tipo de regla, donde los nueve van agrupados por lo que le hacen a la petición —Mock, Passthrough modificado, Redirect y Block, la división que explica Mock vs. passthrough modificado—; el nombre corto entre corchetes es como aparece ese mismo tipo en el listado de reglas, en el filtro de tipo y en la lista de capturas. Una regla hace una sola de estas cosas — pero una petición puede estar gobernada por varias reglas a la vez, así que combinar dos tipos es cuestión de escribir dos reglas. Ver Cuando varias reglas coinciden con la misma petición.

La latencia no es un tipo de regla

Retrasar una petición era un tipo aparte y ha dejado de serlo. Latencia (ms) vive en el bloque Simulación de red del formulario y se aplica a todos los tipos: un mock llega tarde, una redirección sale tarde, una petición cancelada falla tarde. Si dejas el campo vacío la regla no añade ninguna latencia; 0 no es lo mismo que vacío — es una espera real, aunque sea mínima.

Si lo único que quieres es hacer lento un endpoint, usa el tipo Sin cambios (solo retrasar) y ponle una latencia. Las reglas que eran del antiguo tipo Retraso se convirtieron exactamente en eso, conservando sus milisegundos, la primera vez que abriste esta versión.

Sobrescribir el estado de una respuesta real

Hay dos campos en el formulario que son un código de estado HTTP, y no son lo mismo. Es la confusión más fácil de tener aquí, así que va primero:

El caso para el que existe: quieres ver qué hace tu manejo de errores ante un 500 de ese endpoint, pero con los datos de verdad. Con un mock tendrías que escribir el body entero a mano — y entonces ya no estarías probando contra la respuesta real, que era justo lo que querías conservar.

• Se acepta de 200 a 599. Fuera de ese rango el navegador no puede construir la respuesta, así que un valor de fuera no se aplica en vez de romper la petición.
• El texto de estado se queda vacío. Un 500 arrastrando el OK de la respuesta original se contradice a sí mismo en cuanto lo escribes en un log; y un texto vacío es lo que ya entrega el navegador con HTTP/2 y HTTP/3, que no llevan frase de estado.
• Con 204, 205 o 304 el body se cae, porque esos estados no pueden llevar ninguno. Es exactamente lo que hace el navegador con una respuesta real de ese tipo.
• Deja el campo vacío para conservar el estado real: es la única forma de quitar una sobrescritura.
• En una regla que mockea o que cancela la petición no hace nada, y no es un fallo: ahí no hay ninguna respuesta real que sobrescribir. En el panel de Actividad esa regla aparece como coincidente pero no aplicada. Para un mock, el campo que manda es Código de estado.

Y como cualquier modificador, se combina: una misma regla puede sobrescribir el estado y transformar el body de la respuesta, y cambiarle una cabecera, y llegar tarde.

Mock vs. passthrough modificado

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

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. La lista de capturas dice lo mismo con palabras, petición a petición: "llegó a la red" o "no llegó a la red".

Es una propiedad de la petición, no de cada regla por separado: en cuanto una de las reglas que coinciden la mockea, la petición ya no sale del navegador, hagan lo que hagan las demás. Un mock con latencia es una respuesta que llega tarde y que sigue sin llegar al servidor — ver Cuando varias reglas coinciden con la misma petición.

Elegir con qué peticiones coincide una regla

Sea del tipo que sea, toda regla parte de un patrón: el desplegable Origen decide si ese patrón se compara con la URL completa o solo con el Host, y el desplegable Tipo de match decide cómo. Los dos están dentro del bloque Coincidencia avanzada del formulario, plegado hasta que lo abras:

En vez de adivinar, pega una URL real en URL de prueba (opcional), la caja que hay justo debajo del patrón. Responde ✓ Coincide o ✗ No coincide mientras escribes, te dice contra qué ha comparado (la URL entera o solo el host) y te avisa si un patrón Regex no compila. No guarda nada ni lanza ninguna petición. Solo comprueba el patrón, el tipo de match, el origen y las exclusiones — no el método ni las condiciones de header/body/iniciador de más abajo.

Todo lo de /api/ menos el health check

Un patrón lo bastante amplio como para ser útil suele serlo también para atrapar algo que no querías: el health check que tu panel pide cada cinco segundos, la llamada de login, la única petición que ya lleva un token de verdad. Para eso está Excepto URLs que contengan (una por línea), justo debajo de los tres desplegables de Coincidencia avanzada. Un patrón por línea; si alguno aparece en la URL de la petición, la regla la deja en paz.

Dos cosas de esta caja son deliberadas, y conviene saberlas antes de pelearse con ella:

• Se compara siempre contra la URL entera, aunque Origen esté en Host. Es lo que la hace utilizable en las reglas que más la necesitan: una regla acotada por host no tendría más que un nombre de dominio contra el que comparar, y /api/health no aparece en ninguno. De paso, aquí se puede excluir un subdominio entero (static.example.com) igual de fácil que una ruta.
• Es siempre texto literal, diga lo que diga Tipo de match. Ni regex ni comodines: un . es un punto y un * es un asterisco. Las mayúsculas cuentan, como en todo lo demás. Si de verdad necesitas una expresión regular para describir lo que quieres dejar fuera, la salida de siempre sigue estando ahí — un lookahead negativo en el propio patrón, ^(?!.*health).*api.* en modo Regex.

La caja de URL de prueba tiene en cuenta las exclusiones: una URL excluida responde ✗ La excluye «…» y dice qué línea es la responsable, en vez de prometer una coincidencia que no va a ocurrir.

Además del patrón, una regla puede llevar condiciones extra, en Condiciones adicionales (opcional) del formulario —salvo el Método, que está con los otros dos desplegables en Coincidencia avanzada—. Todas son opcionales, y todas tienen que cumplirse a la vez (AND, nunca OR):

• Método — cualquier cosa distinta de "Cualquiera" limita la regla a ese verbo.
• Condición de header (opcional) — un nombre de header más está presente / está ausente / es igual a / contiene / coincide con regex.
• Condición de body — Contiene / Es igual a / Regex sobre el body de la petición saliente. (Los wildcards están disponibles para el patrón de URL y el de iniciador, pero aquí no.)
• Dominio iniciador (opcional) — el host de la página que hace la petición, no el destino, con los mismos cuatro tipos de match que el patrón de URL.
• Fijada a una pestaña (📌 en el popup) — la regla solo se aplica a las peticiones de esa pestaña concreta.

Cuando varias reglas coinciden con la misma petición

Nada impide que dos reglas coincidan con la misma petición, y cuando pasa se aplican todas, no solo la primera. Eso es lo que permite redirigir una llamada y añadirle una cabecera, sin tener que meter las dos cosas en una sola regla.

Se aplican en el orden de la lista, de arriba abajo, y cada regla solo opina sobre la parte de la petición de la que va su tipo: una de headers aporta cambios de cabecera, un mock aporta la respuesta, y cualquiera de ellas puede aportar además una latencia. Cuando dos reglas hablan de lo mismo, gana la que está más abajo en la lista. O sea que el orden de la lista de reglas es la prioridad — con los botones ↑ y ↓ de cada regla la mueves por encima o por debajo de otra, y eso cambia de verdad lo que acaba haciendo tu petición.

Hay dos combinaciones que no las decide el orden de la lista, sino una regla propia:

• Cancelar gana siempre. Si alguna de las reglas que coinciden es un Cancelar petición, la petición falla — esté donde esté en la lista, y digan lo que digan las demás. Una cancelación más un mock es una petición fallida, nunca una mockeada; y si además hay una latencia de por medio, el fallo simplemente llega tarde. Esa es la respuesta a "tengo una regla que cancela y otra que responde, ¿por qué se cancela?": quita de en medio la cancelación (desactívala, o afina su patrón) si lo que quieres es el mock.
• A un mock no le afecta nada de lo que actúa en la vuelta. Una petición mockeada no llega a la red, así que no hay respuesta real sobre la que pueda actuar una regla Modificar el body de la respuesta real —ni el lado de respuesta de una regla Modificar headers— aunque coincidan con esa misma petición. Escribe lo que quieras directamente en el body y en los headers del propio mock.

Para ver qué reglas gobernaron una petición concreta en vez de deducirlo, graba la pestaña y abre la lista de capturas: una petición que coincidió con tres reglas sale con una línea ⚡ por cada una, y la chapa del icono cuenta reglas aplicadas, no peticiones.

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, el texto de reemplazo de una regla "Reemplazar texto en la URL", y tanto el texto de reemplazo como el valor nuevo del campo JSON de una regla "Modificar el body de la respuesta real".

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.

Elige el entorno activo con el botón de estrella junto a él en la página de opciones, o desde el desplegable Entorno 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

Primero, una comprobación rápida que ahorra mucho tiempo: el icono de la extensión en la barra lleva una chapa con el número de reglas aplicadas en la pestaña actual. Si está vacía después de recargar, no ha coincidido nada y la lista de abajo es donde mirar. Si está contando, la regla sí se aplica y la sorpresa está en lo que hace, no en si se ejecuta.

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

1. El interruptor maestro (Activa arriba del popup, Extensión activa en la página de opciones) está apagado. Nada se aplica mientras lo esté.
2. El interruptor propio de la regla está apagado.
3. La regla pertenece a un grupo desactivado. Un grupo desactivado apaga en silencio todas las reglas de dentro — en el listado, esas reglas muestran un ⚠ junto al nombre del grupo.
4. La regla está fijada a una pestaña concreta (📌) y estás probando desde otra.
5. Este sitio está fuera del alcance configurado. Es el que más despista, porque no depende de la regla: si en Alcance (página de opciones) has elegido «Solo localhost» o «Solo estos dominios», en los demás sitios ninguna regla se aplica. El icono de la extensión lo dice — pasa el ratón por encima y verás «fuera de alcance aquí»—, y en ese modo el popup también lo avisa. Ojo con el caso de la lista vacía: «Solo estos dominios» sin ningún dominio escrito no permite nada, en ninguna parte.
6. El método HTTP de la petición no coincide con el Método configurado en la regla (si no está en "Cualquiera").
7. El patrón de URL/host no coincide de verdad — revisa el tipo de match tanto como el patrón en sí, y pega la URL real en URL de prueba (opcional) para salir de dudas. Si 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 — la caja de prueba avisa expresamente de ese caso. Otro clásico: escribir * o ? en un patrón que sigue en "Contiene" o "Es igual a", donde son caracteres literales — solo significan algo en modo Wildcard.
8. La regla tiene un patrón de exclusión que casa con esta URL. Es el motivo más fácil de pasar por alto, porque el patrón positivo sí coincide y todo parece correcto: mira Excepto URLs que contengan dentro de Coincidencia avanzada — el bloque se abre solo cuando la regla trae alguna, y el resumen plegado dice cuántas hay. Pegar la URL en URL de prueba (opcional) lo resuelve en el acto: dice cuál de las líneas la excluye.
9. La regla tiene una Condición de header, una Condición de body o un Dominio iniciador y la petición actual no los 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", "sin cambios", "modificar body de la petición" 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.
10. 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).
11. La petición no ha llegado a ocurrir, porque el navegador la ha resuelto desde su propia caché. No hay nada que interceptar, y se parece exactamente a una regla que no funciona. Usa ↻ Recargar sin caché en el popup para recargar esa pestaña ignorando la caché, o añade una regla Modificar headers con el preset Bypass de caché para que pase en todas las recargas.
12. Otra regla que también coincide la está pisando. Las reglas no se tapan entre ellas —se aplican todas—, pero cuando dos hablan de lo mismo gana la que está más abajo en la lista, y una regla Cancelar petición gana a todo. Así que la regla puede estar aplicándose perfectamente y aun así no dejar rastro: reordena la lista, o afina el patrón de la otra regla. Ver Cuando varias reglas coinciden con la misma petición.
13. La regla tiene un tipo que esta versión no sabe aplicar. Puede pasar al importar un fichero escrito por una versión posterior, o si una actualización dejó una regla a medio migrar. Se ignora solo esa regla, exactamente como si no hubiera coincidido —nunca se responde con un mock vacío, y cualquier otra regla que coincidiera con esa misma petición sí se aplica— y la fila se marca en la lista de capturas con ⚠ y el nombre del tipo no reconocido, para que la situación se vea en vez de parecer tráfico normal. Abre la regla y vuelve a elegirle un tipo.
14. Una regla Modificar el body de la respuesta real sí coincidió, pero la respuesta era un stream en vivo que no se puede bufferizar, así que se dejó intacta a propósito. Ver Cosas que parecen fallos y no lo son; la lista de capturas lo dice con estas palabras: "coincide pero no se aplicó — respuesta en streaming".
15. Tienes dos copias de Net Tinker instaladas a la vez — lo normal es la de la Chrome Web Store más una de desarrollo cargada sin empaquetar. Las dos parchean la misma página, y la que responde primero se lleva la petición, así que la otra copia no ve nada: ni badge, ni línea en la lista de capturas, y la regla que estás mirando parece no hacer nada aunque sí se haya aplicado una. La pista es que la petición claramente se interceptó mientras la extensión que estás mirando no registra ninguna actividad. Desactiva una de las dos.

Ver qué ha pasado de verdad

Adivinar si una regla se ha aplicado es la vía lenta. Hay tres sitios que te lo dicen, y cada uno responde a una pregunta distinta:

• La chapa del icono — un contador en vivo de cuántas reglas se han aplicado en la pestaña actual. Mirarlo no cuesta nada y responde a "¿está pasando algo siquiera?".
• La lista de capturas — un registro guardado de peticiones, con la regla (o las reglas) que coincidieron con cada una. Es la que hay que abrir cuando algo va mal.
• El panel de DevTools — tráfico en vivo mientras trabajas, y el sitio desde el que crear reglas a partir de él. Ver Crear reglas a partir de tráfico real.

La lista de capturas está apagada hasta que la pides. Abre el popup en la pestaña que quieras observar y activa Grabar esta pestaña — solo se capturan las peticiones de esa pestaña. Después abre la lista con 📡 Capturas en la página de opciones (o Ver capturas desde el popup), que muestra el panel Peticiones capturadas.

Cada fila te dice, en este orden: la página, el status, la hora, y luego qué hizo Net Tinker con ella.

• Un ⚡ con un nombre de regla significa que esa petición coincidió con esa regla. Marca Solo aplicadas para esconder el resto, y usa el buscador para filtrar por URL o por nombre de regla. Cuando varias reglas gobiernan la misma petición, cada una sale en su propia línea ⚡, así que ver la misma URL repetida es la lista diciéndote exactamente qué reglas participaron.
• Toda fila con coincidencia dice además llegó a la red o no llegó a la red, que es la forma más rápida de confirmar que un mock es de verdad un mock.
• Un ⚠ significa que la regla coincidió pero no se pudo aplicar — un tipo de regla no reconocido, o una respuesta en streaming que una regla "Modificar el body de la respuesta real" tuvo que dejar en paz. Los dos casos están explicados en Por qué una regla puede no estar aplicándose.
• Ver regla abre la regla que se aplicó; Desactivar esta regla la apaga desde aquí; + Regla crea una regla nueva a partir de esa petición; y pinchando en la fila se abre el Detalle de la petición completo, con los headers y qué se cambió exactamente.

A diferencia del panel de DevTools, estas capturas sí se guardan, así que siguen ahí después de cerrar la pestaña o el navegador. La lista conserva las 200 más recientes y Vaciar la limpia. La grabación se detiene sola si cierras la pestaña que estabas grabando.

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.
• El preset "CORS de desarrollo" no levanta un bloqueo real de CORS. El navegador hace su comprobación de CORS sobre la respuesta que mandó el servidor de verdad, antes de que Net Tinker llegue a tocar los headers de respuesta. Los valores permisivos que escribe el preset solo los ve el código de la página. Sirve para probar cómo se comporta tu código con esos headers; no para saltarse un servidor que no los envía.
• 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.
• Una regla fijada a una pestaña que ya has cerrado no vuelve a dispararse. El id de una pestaña no significa nada una vez esa pestaña desaparece, así que la regla queda inerte para siempre — y volver a abrir la misma página da una pestaña nueva con un id nuevo, que no la recupera. No hace falta la pestaña original: la página de opciones marca esas reglas con 📌 y ofrece un botón 📌✕ que quita la restricción.
• Una regla "Modificar el body de la respuesta real" no hace nada en un XHR con responseType binario. El body solo se puede transformar si responseType es "", "text" o "json"; con "blob", "arraybuffer" o "document" no hay forma de leerlo como texto, así que esa petición concreta vuelve intacta. La regla no está mal — simplemente ahí no puede actuar.
• "Sobrescribir un campo JSON" deja completamente en paz un body que no sea JSON. Lo mismo si la ruta con puntos no lleva a un objeto (por ejemplo user.status cuando user es un texto). El body se devuelve exactamente como llegó, en vez de quedar reescrito a medias o sustituido por una suposición. Para bodies que no son JSON, usa el modo "Buscar y reemplazar".
• "Modificar el body de la respuesta real" se salta las respuestas que son streams abiertos. Transformar un body obliga a leerlo entero primero, y un tipo de medio cuyo contrato entero es mantenerse abierto —text/event-stream (server-sent events), multipart/x-mixed-replace— no termina nunca. Esas respuestas se devuelven intactas, con su stream vivo, y la regla simplemente no se aplica a esa petición; la lista de capturas lo deja anotado como "coincide pero no se aplicó — respuesta en streaming", para que no sea un no-hacer-nada silencioso. El criterio es el tipo de medio, no el tamaño: una respuesta grande normal sí termina, así que se transforma con normalidad — solo que llega de golpe en vez de progresivamente. Las reglas de cualquier otro tipo no tocan el body de la respuesta y no tienen ninguno de los dos efectos.

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. La cabecera muestra Capturando, y al pulsarla pasa a Pausado si prefieres congelar la lista; marca Conservar registro para que no se vacíe al navegar, y Vaciar la limpia.

1. Cada fila tiene un desplegable "+ Regla…" y un botón dedicado Mockear. Elegir un tipo abre el editor de reglas ya relleno con la URL real de esa petición (como match Es igual a, así que solo afecta a esa llamada exacta) y su método. El desplegable ofrece todos los tipos de regla menos el mock, que tiene su propio botón.
2. Una regla creada así llega desactivada salvo que sea un mock o una cancelación — esas dos están completas en cuanto se crean, mientras que el resto son esqueletos todavía vacíos, y activar una "redirección" o un "body de respuesta" vacíos rompería justo el endpoint que estás depurando. Rellénala y luego enciéndela. El panel te dice cuál de las dos cosas ha pasado cada vez.
3. 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.
4. 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.
5. 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.
6. Exportar HAR guarda como fichero .har estándar las peticiones que se ven ahora mismo en la lista, para dárselas a otra persona o cargarlas en otra herramienta. El diálogo enumera los valores sensibles que ha encontrado y ofrece Sanear credenciales (siempre marcado al abrirse) e Incluir cuerpos de respuesta (siempre desmarcado, recortados a 1 MB cada uno, porque son lo que engorda el fichero). Las dos casillas se rearman cada vez que se abre, así que la opción segura nunca queda apagada de una exportación anterior. Un HAR lleva las cabeceras reales de la petición, Authorization incluida, además de las cookies — trata el fichero como una credencial.
7. 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). El filtro del panel también busca por nombre de operación.
8. El panel lista todos los tipos de recurso, pero las reglas solo se pueden aplicar a fetch/XHR. Si creas una desde la fila de una imagen, un script o una hoja de estilos, el panel te avisa: la regla se crea, pero nunca se disparará. La casilla "Solo fetch/XHR" esconde esas filas si prefieres no verlas.

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 o exportas un HAR. Esa es la diferencia con la lista de capturas de la página de opciones, que sí se guarda a propósito.

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

Exportar escribe tus reglas y grupos en un fichero JSON, junto con tus variables y entornos. Exportarlo todo incluye todas las variables que tengas; exportar una selección de reglas incluye solo las variables que esas reglas referencian por nombre, y poda cada entorno a ese mismo conjunto. Cuál es el entorno activo es una preferencia local tuya y nunca va en el fichero.

Como ese fichero acaba compartiéndose, la exportación pasa antes por un diálogo. Ahí se enumera lo que ha encontrado con pinta de credencial, y se marca por ti Sustituir credenciales por __REDACTED__ cuando hay algo que ocultar. Sanear busca nombres que sugieran una credencial — cualquiera que contenga auth, token, secret, password, passwd, apikey, api_key, api-key, credential, signature, cookie o session — y sustituye el valor correspondiente por __REDACTED__. Revisa:

• Los nombres de header, tanto los de un mock como los de las operaciones de headers de petición/respuesta de una regla "Modificar headers".
• Los nombres de los parámetros de una regla "Parámetro de query".
• Los nombres de campo de un body JSON, a cualquier profundidad.
• La query string del propio patrón de URL de la regla y la de una URL de redirección — pero solo la query string. Un segmento de ruta puede ser cualquier cosa, y adivinar ahí destrozaría URL legítimas. Un patrón cuyo tipo de match sea Regex se salta entero, porque partir una regex por ? la corrompería.
• Los nombres de las variables — {{token}}, {{apiKey}} y compañía son el secreto más probable de todo el fichero. Las sobrescrituras de un entorno se juzgan por el nombre de la variable a la que apuntan, así que un token sobrescrito en "Prod" se redacta igual que la variable base.

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, y el diálogo nombra los que no ha podido comprobar para que los revises tú.
• 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. Un flag no es un secreto, y redactarlo solo produciría una regla rota.
• Dos nombres de header que parecen sensibles pero nunca lo son, tenga el valor que tenga: access-control-allow-credentials (un flag CORS fijo) y www-authenticate (el desafío que hace creíble un 401 mockeado).
• Los campos de una regla "Modificar el body de la respuesta real" — el texto que buscas y por el que lo reemplazas, y el valor nuevo del campo JSON. Se exportan tal como los escribiste, así que no dejes ahí un token antes de compartir el fichero.
• 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.

A la vuelta, Importar te deja elegir qué traer y avisa cuando una regla ya existe (mismo tipo, método y patrón), ofreciéndote importarla como copia, omitirla o sobrescribir la existente — con la misma elección, por separado, para las variables cuyo valor difiera del tuyo.