Le pedí que abriera la app del CCTV. Aparecía una dirección IP: 192.168.1.88. Hice un ping desde mi laptop… sin respuesta. La IP ya no estaba activa.

El problema no era técnico, sino de conocimiento: mi cliente no sabía qué era un DVR, mucho menos cómo encontrarlo. No tenía manuales, no recordaba la contraseña del router, y el sistema llevaba más de cinco años funcionando sin mantenimiento.

Yo, por mi parte, llevo más de una década enfocado en desarrollo web, con python, WordPress, SEO técnico, dashboards, y aunque conozco nmap desde hace años, mis flags de escaneo estaban literalmente empolvadas. Pero en lugar de perderme en tutoriales de YouTube o recurrir a herramientas comerciales, decidí buscar el viejo “Sabuesos en la Red: El escaneo de puertos” de Death Master, repasar mis apuntes arrugados de hace una década y desempolvar no solo las banderas de nmap, sino también esa parte de mí que aún sabe cómo hablarle a la red en su propio lenguaje. Así nació la idea de un nuevo proyecto: escribir un script.

Nació NetVortex: un escáner de red para humanos

En unas horas, armé una herramienta minimalista en Python que hiciera cuatro cosas bien:

1. Descubrir todos los dispositivos activos en la red local mediante un barrido ligero de tipo ping scan (-sn en nmap), sin tocar puertos ni servicios todavía.
2. Guardar esa lista de hosts vivos para usarla como entrada en los pasos posteriores, reduciendo así la carga innecesaria sobre nmap: no tiene sentido que escanee puertos en una IP que ni siquiera responde.
3. Aplicar configuraciones simples pero efectivas para obtener, de forma selectiva, la dirección MAC, el sistema operativo estimado y los puertos abiertos — solo en los dispositivos que ya sabemos que existen.
4. Exportar los resultados en un CSV legible, con nombres de columna claros y riesgo categorizado, para que incluso alguien sin conocimientos técnicos pueda identificar al DVR perdido entre decenas de dispositivos.

El resultado fue NetVortex: un escáner interactivo con perfiles (fast, balanced, deep), detección automática de tipo de dispositivo (¿es un router? ¿una cámara? ¿un DVR?) y una valoración de riesgo basada en los servicios expuestos, todo construido sobre la idea de que menos escaneo, pero más inteligente, suele ser más que suficiente.

¿Cómo encontré el DVR?

La herramienta arrancó con un barrido de descubrimiento ligero sobre 192.168.1.0/24: envió pings, ignoró todo lo que no respondió y, en menos de 5 segundos, identificó 14 dispositivos activos. Solo sobre esas IPs vivas lanzó un segundo paso: un escaneo rápido de puertos y una estimación básica de sistema operativo.

Uno de los hosts destacó al instante:

• IP: 192.168.1.105
• Puertos abiertos: 80, 443, 37777
• SO detectado: Linux 3.X
• Tipo: Dispositivo Desconocido
• Riesgo: Alto

Los puertos 37777, 8000, 8800-8803 son clásicos en DVRs de marcas como Dahua, Hikvision, asi que abrí el navegador, fui a http://192.168.1.105, y… ¡login del DVR!

Actualizamos la IP en la app del celular del cliente. Las cámaras volvieron a funcionar.

Por qué esto importa (especialmente para desarrolladores web)

Hoy me especializo en código: frontend, backend, SEO técnico y scripts en Python que convierten el caos en decisiones útiles. Soy, en esencia un geek. Pero antes de esto, pasé más de veinte años en las trincheras del soporte técnico: cableando redes, resucitando servidores y explicándole a Gerentes y Directores qué era una IP.

Con los años, mi foco cambió: del cable al contenedor, del router al CMS. Pero la infraestructura no desaparece solo porque ya no la miremos todos los días.

Cuando un cliente me llama para revisar su página web y de paso me dice que “ya no ve las cámaras en el celular”, no lo hace porque crea que soy mago, lo hace porque en su experiencia, quien entiende de tecnología puede navegar entre capas. Y en ese momento, no se trata de explicarle que “yo hago web, no redes”. Se trata de resolver su problema con lo que tengo: experiencia, herramientas y una mentalidad.

Así que me pregunté:

¿Cómo aplicar la mentalidad del desarrollador moderno a un problema que vive en las capas más bajas de la red, fuera de mi “zona de confort” actual?

La respuesta no fue volver a ser sysadmin. Fue llevar la disciplina del desarrollo a un mundo que antes resolvía con pura intuición. Porque al final, un DVR perdido no es un problema de red: es un problema de información perdida. Y los desarrolladores, más que nadie, sabemos cómo encontrarla, estructurarla y entregarla de forma útil, aunque sea en un CSV que alguien abrirá en Excel.

NetVortex es un solo archivo en Python. Puedes leerlo, modificarlo o integrarlo en tus propios flujos (¿un dashboard de inventario de red? ¿un reporte automático semanal?). Está en mi filosofía: herramientas que enseñan, no que ocultan.

Y si alguna vez vas a ver a un cliente y te piden ayuda con un DVR perdido… ya sabes qué llevar en tu USB.

En un post anterior exploramos las cabeceras HTTP, esas líneas invisibles que controlan caché, seguridad, compresión y más. Hoy damos el siguiente paso lógico: entender los códigos de estado HTTP, cómo usarlos correctamente y por qué un mal uso puede afectar tanto a tus usuarios como a tu posicionamiento en buscadores.

¿Qué son los códigos de estado HTTP?

Los códigos de estado son respuestas numéricas de tres dígitos que un servidor devuelve tras procesar una solicitud HTTP, es decir: Cuando entramos a una pagina web y están definidos oficialmente en la RFC 9110

y se agrupan en cinco clases:

• 1xx (Informativos): La solicitud se recibió y se está procesando.
  Ejemplo: 100 Continue
• 2xx (Éxito): La solicitud se completó con éxito.
  Ejemplo: 200 OK, 201 Created
• 3xx (Redirección): Se necesita una acción adicional para completar la solicitud.
  Ejemplo: 301 Moved Permanently, 302 Found
• 4xx (Error del cliente): La solicitud contiene un error o no se puede cumplir.
  Ejemplo: 404 Not Found, 403 Forbidden
• 5xx (Error del servidor): El servidor falló al procesar una solicitud válida.
  Ejemplo: 500 Internal Server Error, 503 Service Unavailable

Estos códigos no son solo para humanos. Navegadores, bots de búsqueda, APIs y herramientas de monitoreo los interpretan para tomar decisiones automáticas, e incluso Google los revisa constantemente.

Los más comunes (y los más mal usados)

200 OK
Indica que la solicitud se procesó correctamente. Es la señal que el servidor envía al navegador o servicio de que la página o recurso está disponible y funcionando.
No debe confundirse con el contenido: una página puede devolver 200 OK aunque esté en blanco, no muestre información o su diseño falle.

301 vs 302

• 301 Moved Permanently: La URL antigua ya no existe y el contenido se trasladó definitivamente a otra dirección.
  Ejemplo: cambias midominio.com/vieja-pagina a midominio.com/nueva-pagina. Si un usuario o Google visita la URL antigua, será redirigido automáticamente a la nueva y se transfiere la autoridad SEO.
• 302 Found (o Moved Temporarily): La redirección es temporal. La URL original sigue siendo válida, y los motores de búsqueda no transfieren autoridad SEO a la nueva URL.
  Ejemplo: quieres mostrar una promoción temporal en midominio.com/oferta y redirigir a los usuarios a otra página mientras dura la campaña. Cuando termine, vuelves a mostrar la página original sin afectar el SEO.

Error común: usar 302 cuando en realidad la redirección es permanente (como al migrar un sitio) puede perder tráfico orgánico, porque Google no transfiere la autoridad de la URL antigua a la nueva.

404 Not Found vs 410 Gone

• 404: La página no existe por ahora, pero podría volver.
  Ejemplo: un artículo que borraste temporalmente o un enlace roto en tu sitio. Google puede volver a rastrearla más adelante.
• 410: La página fue eliminada de forma permanente y no volverá.
  Ejemplo: un producto que ya no vendes y que quieres quitar del índice de búsqueda. Google desindexa esta URL más rápido que un 404.

Tip: usa 410 cuando quieras limpiar contenido obsoleto de Google, y 404 cuando la ausencia de la página podría ser temporal.

401 Unauthorized vs 403 Forbidden

• 401: Necesitas autenticación. No enviaste credenciales válidas o no iniciaste sesión.
  Ejemplo: intentas acceder a midominio.com/mi-cuenta sin estar logueado; el servidor responde 401 y te pide iniciar sesión.
• 403: Ya estás autenticado, pero no tienes permiso para acceder al recurso.
  Ejemplo: un usuario normal intenta entrar a midominio.com/admin; aunque haya iniciado sesión, no tiene permisos, y el servidor devuelve 403.

Confundirlos genera flujos de autenticación confusos y posibles vulnerabilidades de seguridad.

429 Too Many Requests
Ideal para APIs con rate limiting. Indica: “estás haciendo demasiadas peticiones”. Incluye cabeceras como Retry-After para mejorar la experiencia del usuario.

500 Internal Server Error
Un “cajón de sastre” peligroso. Nunca lo expongas sin contexto ni registro. En producción, muestra una página amigable al usuario, pero conserva el código 500 real para que crawlers y herramientas de monitoreo detecten el fallo.

429 Too Many Requests

Significa que estás haciendo demasiadas solicitudes en poco tiempo.

Ejemplo práctico:

• Una API de pagos permite 100 consultas por hora por usuario. Si excedes ese límite, devuelve 429 Too Many Requests y la cabecera Retry-After: 3600, indicando que debes esperar 1 hora antes de volver a intentar.
• Otro ejemplo: un sitio de login limita a 5 intentos por minuto. Si un bot intenta 50 veces en un minuto, el servidor responde 429 para frenar el abuso.

Protección contra ataques: esto ayuda a prevenir ataques tipo DDoS o scraping masivo, evitando que el servidor se sature.

500 Internal Server Error

Significa que el servidor falló al procesar una solicitud válida, indicando un problema interno.

Ejemplo práctico:

• Tu sitio web tiene un script que genera reportes y falla por un error en la base de datos. Cuando un usuario intenta acceder al reporte, el servidor devuelve 500 Internal Server Error indicando que algo falló internamente.

Buenas prácticas: nunca mostrar detalles técnicos al usuario final; registra el error para monitoreo. Mantener el código 500 real permite que crawlers y herramientas detecten fallos críticos.

SEO y códigos HTTP: un lenguaje que Google entiende

Los códigos de estado HTTP no son un detalle técnico menor: son parte del lenguaje que tu sitio habla con los motores de búsqueda. Usarlos con precisión envía señales claras sobre la salud, estructura y confiabilidad de tu web.

Cada redirección limpia, cada error 404 bien gestionado, cada respuesta 200 con contenido real… suma puntos invisibles que, con el tiempo, se traducen en tráfico, autoridad y conversiones.

Así que la próxima vez que depures una API o configures una redirección, no preguntes solo “¿funciona?”, sino “¿qué código de estado estoy devolviendo?” Porque en la web, incluso los números más pequeños tienen un gran impacto.

Tip técnico rápido: errores 404

Si quieres que tus páginas rotas tengan un buen manejo sin afectar SEO, basta con un pequeño ajuste en tu .htaccess:

ErrorDocument 404 /404.html

Crea una pagina llamada 404.html, Esto hará que cuando alguien llegue a una URL inexistente:

• Se muestre tu página de error personalizada, con estilo y mensaje útil.
• Se devuelva el código 404 real, indicando a Google que la página no existe.

No necesitas ser un experto en servidores: con una línea puedes mejorar la experiencia del usuario y mantener tu SEO limpio.

Rol del Frontend: la parte visible

Es todo lo que el usuario ve en la pantalla, sin importar si es una página web, una red social o el menú de Netflix, es decir, todo con lo que interactúa: botones, formularios, menús, animaciones, tipo de letra y colores.

En el caso de sitios web, se trabaja con HTML, CSS y JavaScript, junto con frameworks como React, Angular o Vue.
Su objetivo es ofrecer una experiencia visual y funcional. Un buen frontend no solo se ve bien: se siente bien, responde rápido, guía al usuario y evita frustraciones; en resumen, determina si la experiencia del usuario será buena o mala.

Rol del Backend: la parte que hace que todo funcione

Si el frontend es la cara visible, el backend es la parte invisible.
Es el encargado de procesar, almacenar y proteger la información que pasa por una web o una aplicación.

Aquí viven la lógica del negocio, las bases de datos, la seguridad, la autenticación y todo lo que el usuario no ve, pero necesita para que la experiencia funcione.
Cuando haces clic en un botón “Enviar”, el backend recibe la información, la procesa y decide qué hacer con ella: guardarla, validarla o generar una respuesta para el usuario.

API: el puente entre mundos

Una API (Application Programming Interface) no es un rol como frontend o backend; es un puente de comunicación que permite que ambos, o incluso otros sistemas, se comuniquen de forma estructurada.

Piénsala como una mezcla entre traductor y manual de procedimientos: traduce las peticiones de un sistema al otro y define las reglas de cómo debe realizarse esa comunicación.
Es decir, la persona encargada del frontend y la del backend no necesitan programar desde cero algo que ya existe, como los servicios que ofrece Google.

Gracias a las APIs, un sitio web puede conectarse con servicios externos sin tener que desarrollar por completo.

Por ejemplo:

• Cuando usas una app para pedir comida y ves el mapa de ubicación del repartidor, esa información proviene de la API de Google Maps.
• Cuando pagas con PayPal o Mercado Pago, la transacción se gestiona mediante su API de pagos.

Son conexiones invisibles que hacen posible la interoperabilidad moderna.

Rol Full Stack: quien ve el panorama completo

El desarrollador Full Stack entiende tanto el frontend como el backend, y sabe cómo conectarlos a través de APIs.
No significa que domine cada tecnología del ecosistema, sino que comprende perfectamente el flujo completo, desde que el usuario hace clic hasta que los datos llegan y regresan del servidor.

Es un perfil versátil, capaz de moverse entre ambos mundos sin perder de vista el objetivo final: que todo funcione bien y tenga sentido.

Conclusión

Cada rol cumple una función distinta, pero todos apuntan al mismo fin: crear soluciones que funcionen y mejoren la experiencia del usuario.
No se trata de jerarquías ni de títulos rimbombantes, se trata de entender cómo cada pieza encaja en el desarrollo.