Blog
Resolución de problemas de conexión del iPhone: redes locales y Tactic Relay
¿Qué demuestran una misma red Wi-Fi, un equipo en la lista o un puerto con respuesta? Localiza la última fase operativa, conserva la sesión original y valida con una solicitud pequeña.
Puedes conectarte al Mac en casa, pero falla en una cafetería. El equipo aparece en la lista de tu cuenta, pero abrir un proyecto se queda en tiempo de espera constante. O la terminal se muestra en pantalla, pero no llega ninguna respuesta nueva. Estas tres situaciones parecen fallos de conexión idénticos, aunque el punto que requiere verificación es distinto en cada caso.
Al investigar la incidencia, empieza por «la última fase que funcionaba con certeza». Si el ordenador ni siquiera está en marcha, restaura primero el host. Si la conexión local falla pero una conexión Relay ya configurada funciona, inspecciona la red local. Si la sesión original muestra actividad de terminal en tiempo real, pasa a examinar el estado del agente. De este modo, cada paso aporta un resultado evaluable y protege las tareas en curso.
Registra el estado actual antes de modificar la configuración de red
Anota el nombre del ordenador, el proyecto y la sesión, el método de conexión, el texto exacto del error y la hora aproximada. Comprueba también si se han producido cambios recientes: cambio de red, suspensión del equipo, actualización del host o cancelación de inicio de sesión.
No empieces desvinculando el ordenador, borrando sesiones o restableciendo todos los parámetros de red. Esas acciones alteran la autorización previa o el estado de trabajo sin resolver la suspensión del sistema ni el aislamiento de redes para invitados. Modifica una sola condición relevante cada vez y compara los resultados.
La secuencia descrita a continuación está pensada para diagnosticar conexiones existentes. Para la configuración inicial, sigue la guía de inicio en iPhone para instalar el asistente y completar el emparejamiento.
Ambos métodos comparten el mismo ordenador de desarrollo, pero atraviesan etapas de red y autorización distintas. Comprueba la ruta que estés usando en la práctica.
Paso 1: Comprueba que el ordenador y el servicio asistente siguen en ejecución
El equipo debe encontrarse en un estado apto para trabajar y la aplicación asistente o el servicio CLI deben estar activos. Una pantalla apagada no equivale a un equipo en suspensión. Que el ordenador aparezca en la lista de tu cuenta tampoco valida la conexión actual. Comprueba en el host el estado del servicio, la ausencia de errores y la certeza de estar apuntando al equipo previsto.
En macOS, puedes ejecutar este comando de solo lectura para comprobar el puerto predeterminado:
El puerto predeterminado es el 8765. Si lo has modificado, utiliza el puerto configurado. Los campos COMMAND, PID y la dirección de escucha ayudan a identificar qué proceso está prestando el servicio.
| Resultado | Qué indica | Siguiente paso |
|---|---|---|
| Sin salida | La comprobación no encontró procesos a la escucha en ese puerto | Verifica si el servicio se ha iniciado, si registró errores y si el puerto coincide |
| Proceso a la escucha | Hay un servicio local escuchando en el puerto | Contrasta el proceso con el estado del asistente y revisa la ruta desde el teléfono |
| Escucha solo en loopback | La dirección de escucha solo es accesible desde el propio equipo | Revisa la configuración de red local del servicio; mantén la autenticación activada |
| Proceso inesperado o conflicto de puerto | Es posible que estés conectando a otro servicio | Identifica el proceso antes de considerar si conviene detenerlo |
Esta comprobación no valida la identidad en Tactic ni garantiza que el iPhone pueda conectar. Tanto la app para Mac como la CLI independiente pueden utilizar el mismo puerto por defecto; aclara cuál de las dos has iniciado. Si no puedes inspeccionar el ordenador en persona, mantén el estado del host como «no confirmado» y continúa analizando los errores del teléfono.
Paso 2: En conexiones locales, comprueba los permisos y la accesibilidad real
Que dos dispositivos muestren el mismo nombre de red Wi-Fi no garantiza que puedan comunicarse. Las redes de invitados, las políticas de aislamiento corporativo y las rutas VPN pueden bloquear la conexión. En el iPhone, ve a Ajustes → Privacidad y seguridad → Red local y comprueba los permisos de Tactic Remote; la guía de permisos de red local de Apple detalla esta opción.
A continuación, compara la dirección IP actual del ordenador con la guardada en la aplicación. Un cambio de router, el paso de Wi-Fi a Ethernet o una nueva concesión DHCP pueden hacer que la dirección guardada apunte a otro dispositivo. Guíate siempre por la dirección que muestra el asistente del host y no asumas que la Wi-Fi de todo Mac es en0.
Si dispones de otro Mac en la misma red de confianza, puedes verificar la conexión TCP hacia el equipo de desarrollo:
Este comando solo intenta establecer un enlace TCP; no transmite credenciales de Tactic ni instrucciones de código. La opción -G 3 define el tiempo de espera de conexión en el nc de macOS; en otros sistemas los parámetros varían.
| Resultado | Cómo interpretarlo |
|---|---|
| Conexión correcta | El dispositivo de prueba alcanza el puerto de destino; la autenticación de Tactic y la ruta del iPhone requieren comprobaciones independientes |
| Connection refused | La solicitud de conexión fue rechazada activamente. Comprueba el puerto, el servicio, la configuración de escucha y las reglas de filtrado. Esto no valida la autenticación de Tactic ni determina qué equipo emitió el rechazo |
| Tiempo de espera agotado | No se ha recibido respuesta; revisa la IP, el aislamiento entre equipos, el enrutamiento, el cortafuegos y el estado del host |
Probar 127.0.0.1 en el propio equipo de desarrollo solo lo evalúa a sí mismo. En el navegador del iPhone, 127.0.0.1 apunta al teléfono, no al Mac. Asimismo, que un ping falle no demuestra por sí solo que el servicio esté fuera de línea, ya que la red puede bloquear ICMP.
Si necesitas ajustar el cortafuegos, autoriza únicamente el acceso requerido por el asistente en ejecución y mantén la autenticación. Si utilizas VPN, analiza los cambios de enrutamiento respetando las normativas de tu organización. Desactivar todo el cortafuegos, anular la autenticación o abrir puertos en el router no deben ser métodos habituales de recuperación. Consulta la configuración básica en la guía de red local.
Paso 3: En Relay, comprueba el estado de la cuenta y del host
Al salir de casa, el teléfono deja de tener acceso a la dirección de red local de tu equipo doméstico. Para usar Tactic Relay, confirma que ambos dispositivos han iniciado sesión en la cuenta de Tactic prevista, que el ordenador está vinculado y que el asistente del host mantiene activa la conexión Relay.
Comprueba estos puntos por orden:
- El equipo está activo, el asistente en ejecución y la conexión a Internet operativa.
- Teléfono y ordenador tienen la sesión iniciada en la cuenta correcta y has seleccionado el equipo adecuado.
- El ordenador indica que Relay está conectado con normalidad, en lugar de estar reconectando o mostrando un error concreto.
- Se ha completado cualquier solicitud de verificación de cuenta, renovación de inicio de sesión o retorno del navegador a la app.
- Tras resolver esos avisos, conecta de nuevo al equipo y abre el proyecto.
El inicio de sesión en Tactic gestiona la vinculación del host y la autorización de acceso. Los agentes de programación como Claude Code utilizan sus propias cuentas de proveedor en el equipo de desarrollo. Ver un ordenador en la cuenta, conectar a su espacio de trabajo y tener un agente con sesión iniciada son estados completamente independientes.
La versión 1.11 corrige un problema por el cual la vinculación del equipo podía fallar un tiempo después de iniciar sesión. Si aparece un aviso de verificación, complétalo antes de reintentar la vinculación. Desvincular y revincular repetidamente añade más variables que verificar; no debe ser la respuesta inicial ante cualquier tiempo de espera.
Si tienes ambos métodos configurados correctamente, puedes compararlos para aislar el fallo: si la red local falla pero Relay funciona en el mismo equipo, investiga primero la red local; si la red local funciona pero Relay falla, prioriza la verificación de la cuenta, el estado de Relay en el host y la salida a Internet. La comparación acota el diagnóstico, pero no demuestra que un componente concreto esté totalmente libre de fallos.
Si utilizas Cloudflare Tunnel, verifica su dirección por separado
En Cloudflare Tunnel, comprueba el proceso del túnel, su URL actual y el servicio al que apunta en la práctica. Al reiniciar un túnel temporal, la dirección puede variar, por lo que una URL guardada puede no corresponder ya al equipo actual.
Que una página HTTP cargue en el navegador no demuestra por sí solo que la conexión WebSocket o la autenticación de la app funcionen. Conserva el mensaje de error íntegro, confirma la dirección actual y sigue la guía de configuración de Cloudflare Tunnel. No modifiques a la vez las reglas del túnel y la vinculación de cuentas de Tactic Relay.
Paso 4: Vuelve a la sesión original y valida la llegada de nueva salida
Tras conectar, selecciona el ordenador, el proyecto y la sesión previa al fallo. Si puedes listar los proyectos, el acceso al espacio de trabajo se ha restablecido. Si observas cambios en tiempo real en la terminal original, la salida de la sesión llega de nuevo al teléfono. El historial antiguo solo demuestra actividad pasada; no garantiza que la conexión actual sea funcional.
Si la terminal se encuentra a la espera de la confianza del proyecto, el inicio de sesión del proveedor o una confirmación de inicio, consulta la guía para agentes en espera. Cambiar de Wi-Fi o revincular la cuenta no resolverá esa solicitud dentro de la terminal.
Si la desconexión se produjo al pulsar Enviar, busca primero salida nueva que corresponda a esa petición; es posible que ya haya alcanzado el equipo. Tras reconectar, no reenvíes de inmediato la tarea completa. Una vez confirmado que la sesión está libre, puedes enviar una consulta de estado de alcance reducido:
Ofrece un resumen de solo lectura del proyecto actual, el trabajo ya completado y cualquier elemento pendiente de decisión. No vuelvas a ejecutar la tarea anterior ni edites archivos.
Comprueba que la ruta y los resultados coinciden con la tarea original antes de decidir los siguientes pasos. Si necesitas abrir una sesión nueva, documenta antes el estado real de la anterior; una nueva sesión no hereda de forma automática el contexto completo.
Si el problema persiste, facilita el diagnóstico al equipo de soporte
Puedes copiar esta plantilla y rellenar los datos comprobados; indica «no confirmado» en los puntos que no hayas podido verificar.
Antes de compartir la información, elimina credenciales, códigos QR de emparejamiento, enlaces de acceso y contenido privado de la terminal. Oculta cuentas, rutas y direcciones de red según sea necesario. Enviar a soporte un diagnóstico concreto como «El puerto local responde, la app muestra fallo de verificación y la versión del host es...» ayuda más a localizar la causa que limitarse a indicar que no conecta.
Una vez recuperada la conexión, coteja ambas versiones con la página de descargas para evitar que una disparidad no resuelta vuelva a causar problemas en el próximo uso remoto. Para consultar el resto de novedades de la versión 1.11 y cómo actualizar la app y el asistente del host, lee la visión general de Tactic Remote 1.11.
Prueba Tactic Remote
Controla tus agentes de programación desde el móvil
Conéctate a Claude Code, Codex y otros agentes en tu Mac, Windows o Linux. Consulta el progreso y envía la siguiente instrucción desde el iPhone o iPad.