Portless: rutas locales con nombre
Arquitectura de Portless: estado de control y reenvío HTTP por loopback
Sigue el registro del lanzador, las rutas por petición y los límites de protocolo sin confundir almacenamiento persistente con la biblioteca del proxy.
Qué aprenderás
- Separa registrar de reenviar
- Sigue una petición ordinaria
- Los protocolos añaden ramas, no garantías universales
Antes de empezar
- Conceptos de orígenes HTTP, puertos y terminal
- Distinguir loopback, LAN y exposición pública
Traza una petición, define límites de instalación y separa comportamiento observado de integraciones no probadas.
Conclusiones clave
- Registrar rutas y reenviar HTTP son responsabilidades separadas.
- La conexión interna utiliza loopback, no DNS remoto arbitrario.
- Soporte en código no equivale a compatibilidad completa del navegador.
Separa registrar de reenviar
El lanzador y el almacén de rutas gestionan nombres, puertos y propiedad de procesos. La biblioteca recibe getRoutes y lo invoca en cada petición. Esa interfaz permite que createProxyServer ignore cómo se dedujo el nombre o dónde se guardó una ruta. Nuestro experimento entregó una lista en memoria y añadió una ruta accesible sin reiniciar el proxy.
RouteStore es el componente de persistencia separado. Valida campos básicos y puede filtrar registros cuyo proceso ya no vive; pid 0 representa una ruta estática. Sus bloqueos y limpieza pertenecen al plano de control, no al protocolo HTTP. Además, un identificador de proceso no es una identidad permanente: correlaciona la ruta con el proceso actual y el listener real.
Sigue una petición ordinaria
En HTTP/1.1, Host selecciona la ruta; la compatibilidad HTTP/2 puede utilizar :authority. Después, createLoopbackConnection conecta al puerto elegido y limita explícitamente sus direcciones a 127.0.0.1 y ::1. El host aportado por el navegador es una clave de ruta, no un destino DNS remoto arbitrario para esa conexión al servidor.
El manejador transmite método, ruta y cuerpo, conserva el host original y construye cabeceras de reenvío. Nombres desconocidos generan una página del proxy, fallos de conexión producen un error de pasarela y el contador detecta bucles suficientemente profundos. Son fronteras diferentes: registra primero qué nombre coincidió y si la aplicación escuchaba antes de investigar el renderizado de la respuesta.
Los protocolos añaden ramas, no garantías universales
Con opciones TLS, la implementación crea un servidor HTTP/2 seguro con compatibilidad HTTP/1.1. También distingue WebSocket Upgrade clásico y CONNECT extendido de HTTP/2, adaptado a un saludo HTTP/1.1 del servidor. Estas ramas explican el diseño, pero su presencia no demuestra que todos los navegadores y frameworks recarguen correctamente.
La prueba acotada ejercitó solo HTTP/1.1 sin TLS. No utilizó certificados, almacén persistente, servicio del sistema ni procesos externos de acceso compartido. Esa separación hace interpretable el resultado: se observó el enrutamiento dinámico mediante callback, mientras que certificados, arranque persistente y HMR siguen siendo comprobaciones de integración del responsable del despliegue.
Pasos de implementación
- 1
Localiza lanzador y RouteStore para el registro.
- 2
Sigue getRoutes hasta el manejador.
- 3
Traza Host y el puerto loopback seleccionado.
- 4
Añade pruebas por protocolo sin ampliar las conclusiones del experimento HTTP.
Ejemplo para copiar
Lanzador / RouteStore -> getRoutes()
Host del navegador -> ruta -> conexión loopback -> aplicación
| sin coincidencia: 404
| fallo del servidor: 502
| límite de saltos: 508
TLS / HTTP2 / WebSocket: inspeccionados, no probados aquíPreguntas frecuentes
¿Cada cambio de ruta exige reiniciar?
La interfaz de biblioteca no lo exige: invoca getRoutes por petición. La prueba añadió una ruta en memoria sin reinicio; el registro persistente de CLI tiene su propio ciclo.
¿Host se convierte en destino remoto?
En el conector inspeccionado selecciona un puerto registrado y la búsqueda devuelve direcciones loopback. Las integraciones de acceso público son componentes diferentes.
Fuentes
- packages/portless/src/proxy.tsFuente verificada 2026-09-08
- packages/portless/src/routes.tsFuente verificada 2026-09-08
- packages/portless/src/utils.tsFuente verificada 2026-09-08
- packages/portless/src/types.tsFuente verificada 2026-09-08