Hay una fase del homelab en la que miras demasiado el servidor y demasiado poco el WiFi. Me ha pasado. Algo va lento, una app tarda en cargar, Home Assistant responde a ratos, el móvil no abre un panel interno, una cámara pierde conexión o una copia desde el portátil parece arrastrarse. Lo primero que haces es mirar contenedores, CPU, discos, DNS, reverse proxy, logs y cualquier cosa que huela a infraestructura seria.
Luego descubres que el móvil estaba conectado al punto de acceso equivocado, con señal mediocre, pasando por un backhaul inalámbrico saturado y resolviendo DNS con más esperanza que método.
Bonito, ¿eh?
En una casa real, el WiFi es parte del homelab aunque no lo parezca. Si usas servicios internos desde móviles, tablets, portátiles, teles, cámaras, sensores o domótica, la experiencia no depende solo de que el servidor esté sano. Depende de que la red inalámbrica lleve esos paquetes sin convertir cada pared en una negociación diplomática.
Por eso cada vez miro el WiFi antes cuando algo raro ocurre. No siempre es el culpable, pero muchas veces participa en el crimen.
El síntoma engañoso: “el servidor va mal”#
La frase suele llegar disfrazada:
- “La app de fotos tarda mucho”.
- “No carga Home Assistant”.
- “La tele se queda pensando”.
- “Desde el portátil va fatal”.
- “En el móvil no abre, pero en tu ordenador sí”.
Si desde un equipo cableado el servicio responde bien y desde un móvil en otra habitación responde mal, el servidor quizá no tiene la culpa. Puede haber un problema de cobertura, interferencias, roaming, DNS, mDNS, multicast o simplemente una ruta WiFi horrible.
El error es diagnosticar todo desde el rack o desde el despacho. Ahí normalmente tienes buen cable, buen AP cerca y poca fricción. La casa no vive en el rack. Vive en el sofá, la cocina, el dormitorio, el pasillo, la terraza y ese rincón exacto donde la señal decide morir con dignidad.
Para servicios domésticos, pruebo desde donde se usan. Si Paperless-ngx solo lo uso en el ordenador cableado, perfecto. Si Immich sube fotos desde móviles por WiFi, tengo que probar desde móviles. Si Home Assistant controla luces desde el salón, el salón importa. Si una cámara IoT vive en la otra punta, esa esquina importa más que cualquier gráfica bonita.
Primero separo red cableada y WiFi#
Cuando algo va lento, mi primera prueba es muy simple: cable contra WiFi.
Desde un equipo cableado pruebo:
- abrir el servicio
- resolver el nombre interno
- medir latencia básica
- subir o bajar un archivo pequeño si aplica
- comprobar que el servidor responde estable
Luego hago lo mismo desde el dispositivo WiFi que falla. Si cable va bien y WiFi va mal, no sigo quemando tiempo en la VM. Me voy a la capa inalámbrica.
Esta separación ahorra horas. El WiFi introduce variables que el cable no tiene: señal, ruido, banda, ancho de canal, roaming, potencia, backhaul, ahorro de energía del cliente, drivers malos y vecinos con routers gritando en el mismo canal.
No hace falta montar un laboratorio para verlo. Basta con medir desde dos sitios y dejar de tratar “la red” como una sola cosa.
Una red doméstica puede estar perfectamente cableada y tener un WiFi mediocre. También puede tener buen WiFi para navegar y mal WiFi para mover datos internos. YouTube disimula mucho porque cachea, adapta calidad y tolera latencia. Una app self-hosted interna puede ser bastante menos amable.
Cobertura no es velocidad máxima#
El marketing del WiFi habla de velocidades enormes. En casa, lo que me interesa antes es estabilidad.
Prefiero 200 Mbps estables con buena latencia a una conexión que enseña 900 Mbps en una prueba y luego se queda tonta cuando te mueves tres metros. Para homelab, especialmente con servicios internos, la regularidad pesa más que el pico.
Hay tres señales que miro:
- intensidad de señal razonable
- latencia estable hacia el gateway o un host interno
- pérdida de paquetes baja
No necesito obsesionarme con cada dBm, pero sí saber si una zona está en el borde. Muchas veces un dispositivo parece conectado, pero está sobreviviendo. Carga webs externas porque todo está optimizado para redes malas, pero cuando le pides acceder a un servicio interno con DNS propio, HTTPS interno y una app menos pulida, empiezan los síntomas raros.
También hay que distinguir cobertura de capacidad. Puedes tener señal en toda la casa y aun así saturar un AP si hay demasiados clientes, cámaras, streaming, copias y móviles actualizando. Una barra llena no significa que la red esté cómoda.
El backhaul manda más de lo que parece#
Los sistemas mesh son cómodos, pero tienen una trampa: si los nodos se comunican entre ellos por WiFi, la calidad del backhaul decide mucho. Puedes estar al lado de un nodo mesh con señal perfecta y aun así tener mala experiencia si ese nodo habla con el principal a duras penas.
Por eso, si puedo, cableo los puntos de acceso. Ethernet sigue siendo el mejor amigo del WiFi. Suena contradictorio, pero es así. Un AP con backhaul cableado deja de gastar aire hablando con otros nodos y puede concentrarse en clientes.
Si no puedo cablear, coloco los nodos mesh pensando en el enlace entre ellos, no solo en tapar agujeros. El error típico es poner un nodo justo donde no llega señal para “ampliar”. Si a ese sitio no llega bien la señal, el nodo tampoco tiene magia. Repite una señal mala y encima añade latencia.
La colocación buena suele estar a medio camino: suficientemente cerca del nodo principal para tener buen backhaul y suficientemente cerca de la zona débil para mejorar clientes.
En una casa con homelab, el backhaul afecta mucho a:
- copias desde portátiles
- subida de fotos desde móviles
- streaming interno desde NAS
- cámaras WiFi
- paneles de Home Assistant
- sincronización de carpetas
Si esos usos son importantes, cablear APs merece más que comprar otro mini PC.
Roaming: cuando el móvil se queda pegado al AP equivocado#
El roaming doméstico es fuente de problemas muy tontos. Te mueves por casa, el móvil sigue conectado al punto de acceso lejano porque aún lo oye, aunque tenga otro mejor al lado. Resultado: señal pobre, latencia rara y tú mirando logs del servidor.
Los APs modernos ayudan con tecnologías de asistencia al roaming, pero el cliente decide mucho. Algunos dispositivos son cabezones. Algunos IoT son directamente de museo. Y algunos móviles prefieren aguantar una conexión mala antes que cambiar.
Si una app va mal solo en ciertas zonas o después de moverte, miro a qué AP está conectado el cliente. En controladores tipo UniFi, Omada, MikroTik o sistemas mesh decentes suele verse. Si no, al menos puedo hacer pruebas cortas desactivando WiFi, reconectando y comparando.
También reviso potencia de emisión. Poner todos los APs a potencia máxima no siempre mejora. A veces crea celdas demasiado grandes y clientes que no saltan cuando deberían. Bajar potencia puede mejorar roaming si hay varios APs bien colocados.
No hay una receta universal. Depende de paredes, vecinos, clientes y plano de casa. Pero sí hay una idea útil: más potencia no equivale a mejor red.
2,4 GHz, 5 GHz y 6 GHz sin fanatismo#
En casa uso cada banda para lo que sirve.
2,4 GHz llega más lejos y atraviesa mejor, pero está más saturada y tiene menos capacidad. Es buena para muchos dispositivos IoT, sensores y cacharros que solo necesitan poca velocidad. También es la banda donde viven demasiados aparatos baratos con firmware discutible.
5 GHz suele ser el punto dulce para móviles, portátiles, tablets y servicios internos. Mejor velocidad, menos saturación en muchos entornos y latencia decente si la cobertura acompaña.
6 GHz, si tienes WiFi 6E o WiFi 7, puede ser fantástica en distancias cortas y con clientes compatibles. Pero no arregla paredes. Es más exigente con la distancia. La usaría para zonas donde hay buena cobertura, no como parche milagroso.
No mezclaría todo sin mirar. Para IoT, muchas veces prefiero SSID separado en 2,4 GHz. Para dispositivos principales, un SSID normal con 5 GHz fuerte. Para laboratorio o invitados, redes separadas si hay razón.
Separar demasiados SSID también tiene coste. Cada red adicional añade beacons, configuración y posibilidades de error. No montaría cinco redes porque suena ordenado. Montaría las necesarias.
DNS interno visto desde WiFi#
El DNS es otra fuente de confusión. Puede funcionar perfecto desde cable y fallar desde WiFi si las redes no tienen las mismas reglas, el cliente recibe otro resolver por DHCP, la VLAN WiFi tiene restricciones o el móvil usa DNS privado propio.
Cuando un servicio interno no abre desde WiFi, no asumo que la app está caída. Compruebo:
- qué DNS recibió el cliente
- si resuelve el nombre interno
- si llega al reverse proxy
- si la red WiFi permite esa ruta
- si hay DNS privado en Android o perfiles raros en iOS
Esto es especialmente importante si separas IoT, invitados, LAN y laboratorio. Una red de invitados no debería ver todo. Una red IoT quizá tampoco. Pero si tu móvil está en una red limitada y esperas abrir servicios internos, tienes que decidir si esa ruta debe existir.
Me gusta que el DNS interno tenga un plan claro:
- nombres internos para servicios de casa
- resolvers redundantes si el DNS afecta a navegación
- fallback que no deje a la familia sin internet
- reglas explícitas entre VLANs
- pruebas desde clientes reales
Lo que no me gusta es que todo dependa de “en mi portátil funciona”.
IoT: cobertura mala y dispositivos tercos#
Los dispositivos IoT son una categoría aparte. Muchos solo soportan 2,4 GHz. Algunos tienen antenas flojas. Otros gestionan fatal cambios de AP. Otros se quedan sin conexión y vuelven cuando quieren. Cámaras, enchufes, sensores, robots, teles, altavoces y aparatos varios pueden convertir el WiFi en una colección de excepciones.
Para IoT, priorizo estabilidad sobre velocidad:
- 2,4 GHz bien planificada
- señal suficiente donde viven los dispositivos
- SSID simple si hace falta
- reglas de red limitadas
- pocos cambios de nombre o seguridad
- evitar depender de multicast entre redes si no lo entiendo bien
Si Home Assistant depende de varios dispositivos WiFi, la cobertura IoT es parte del servicio. No sirve de nada que Home Assistant esté perfecto en el servidor si el sensor del pasillo aparece y desaparece.
También soy prudente con WPA3 en redes IoT. Me gusta la seguridad, pero algunos cacharros baratos se llevan mal con configuraciones modernas. Si algo crítico no conecta bien, prefiero segmentarlo y mantener compatibilidad antes que fingir que todos los dispositivos viven en 2026.
Cómo haría un diagnóstico rápido#
Cuando alguien dice que un servicio interno va mal desde WiFi, seguiría este orden:
- Probar el servicio desde cable.
- Probar el servicio desde WiFi cerca del AP principal.
- Probar desde la zona donde falla.
- Mirar a qué AP y banda está conectado el cliente.
- Comprobar DNS desde ese cliente.
- Medir latencia hacia gateway y servidor.
- Revisar si hay pérdida de paquetes.
- Cambiar de AP o reconectar para comparar.
- Revisar backhaul si es mesh.
- Solo entonces mirar logs profundos del servicio.
Este orden no es glamuroso, pero evita perseguir fantasmas. Si el servicio falla igual por cable, me voy al servidor. Si falla solo en una zona WiFi, me quedo en red inalámbrica.
La prueba que más información aporta suele ser moverse. Si en el despacho va bien, en el salón regular y en la habitación fatal, no hay misterio místico. Hay radiofrecuencia, paredes y diseño de red.
Diseño práctico para una casa con homelab#
Si diseñara el WiFi de una casa con homelab desde cero, haría algo bastante simple.
Primero, cablearía todo lo que no se mueve: servidor, NAS, sobremesa, consola si se puede, tele principal si hay toma cerca, puntos de acceso y cualquier equipo que haga backups grandes. El WiFi queda para lo que se mueve o no puede cablearse.
Segundo, pondría APs donde dan servicio, no donde quedan bonitos ni donde hay un enchufe libre. Mejor menos APs bien colocados y cableados que muchos nodos mesh peleando entre ellos.
Tercero, separaría redes con moderación:
- LAN principal para equipos de confianza
- IoT para dispositivos menos fiables
- invitados sin acceso al homelab
- laboratorio solo si aporta algo claro
Cuarto, probaría desde móviles, no solo desde un portátil bueno. El móvil es el cliente real para muchas cosas: fotos, domótica, paneles, notificaciones y apps familiares.
Quinto, documentaría qué depende del WiFi. Cámaras, sensores, subida de fotos, acceso a servicios internos, tablets de casa, impresoras y cualquier cacharro que luego parezca “misteriosamente inestable”.
Qué no haría#
No compraría otro router más caro sin medir antes. Cambiar hardware puede ayudar, pero también puede ocultar que el AP está mal colocado, que el backhaul es malo o que el cliente se agarra al nodo equivocado.
No pondría canales enormes porque sí. Anchos de canal más grandes pueden dar más velocidad, pero también más interferencia y menos estabilidad según el entorno. Para un piso con vecinos, a veces ser conservador funciona mejor.
No mezclaría invitados e IoT con la LAN principal por pereza si hay servicios sensibles. Pero tampoco montaría una red tan segmentada que imprimir o usar AirPlay se vuelva una penitencia. La seguridad doméstica tiene que convivir con la vida doméstica.
No asumiría que mesh equivale a buena red. Mesh puede ser perfecto para algunas casas. Con backhaul cableado, mejor. Sin cable, depende muchísimo de colocación y entorno.
Y no culparía al servidor antes de probar desde cable. Ese pequeño hábito ahorra mucha tontería.
Mi criterio final#
El WiFi del homelab no va de conseguir el número más alto en un test. Va de que los servicios domésticos funcionen donde se usan.
Si Immich sube fotos desde móviles, mide desde móviles. Si Home Assistant se usa en el salón, prueba en el salón. Si una cámara vive lejos, comprueba esa esquina. Si una tablet familiar abre servicios internos, mira su DNS y su AP. La infraestructura real no termina en el switch.
Para mí, la mejor mejora WiFi casi siempre es menos espectacular de lo que apetece: APs cableados, buena ubicación, potencia ajustada, DNS claro, redes separadas con moderación y pruebas desde clientes reales.
Cuando haces eso, desaparecen muchas falsas averías del homelab. El servidor deja de cargar con culpas que eran de cobertura. Y tú dejas de mirar logs de Proxmox cuando el problema era una pared, un móvil terco y un nodo mesh puesto donde no debía.