Empieza con VoidPort

Inicio rápido

Pon tu servidor local en línea en menos de 2 minutos.

1. 1

   Crea una cuenta

   Regístrate en voidport.app/register y elige un plan.

2. 2

   Crea un túnel en el dashboard

   Ve a Dashboard > Tunnels > Crear túnel. Elige qué alojas y una región.

Listo. Tu servidor ya es accesible en la dirección pública que aparece en el dashboard.

Instalación

En Windows, el instalador coloca voidport.exe en %LOCALAPPDATA%\VoidPort y lo añade a tu PATH. En macOS y Linux se instala en /usr/local/bin, o en ~/.local/bin sin root ni sudo.

Descarga manual

Descarga los binarios directamente:

• Linux x64
• Linux ARM64
• Windows x64
• macOS Apple Silicon
• macOS Intel

Comprobar la instalación

$ voidport --version

Crear un túnel

Desde el dashboard

1. Inicia sesión en tu dashboard
2. Haz clic en «Crear túnel»
3. Elige qué alojas, o «Puerto personalizado» con TCP, UDP o ambos
4. Ponle un nombre (p. ej. «minecraft») y elige una región (Núremberg, Helsinki, Ashburn o Hillsboro)
5. Si el servidor se ejecuta en otro equipo, indica su host de destino
6. Haz clic en «Crear túnel», inicia la CLI y luego haz clic en «Probar conexión»

Al crearlo, el dashboard muestra el token de tu túnel y el comando para iniciarlo. Puedes volver a encontrar ambos en la página del túnel. Mantén el token en secreto.

Iniciarlo

Ejecuta esto en el equipo que aloja tu servidor:

$ voidport connect <token>

Redirigir a otro puerto local solo esta vez:

$ voidport connect <token> --port 25566

Ejecutar varios túneles en una sola ventana, por ejemplo juego y chat de voz:

$ voidport connect <token1> <token2>

Con la CLI

También puedes crear y ejecutar túneles desde la terminal. Para ello necesitas hacer voidport login una vez.

$ voidport login

$ voidport tunnel --preset minecraft-java

voidport up inicia todos los túneles guardados en este equipo, voidport list los muestra.

Otros equipos y Docker

Por defecto, la CLI redirige al equipo en el que se ejecuta. Si tu servidor está en otro sitio, define el host de destino del túnel: en el formulario de creación, en la página del túnel en Ajustes, o con voidport tunnel --host. El comando de inicio sigue siendo voidport connect <token>; la CLI toma el host de destino por sí sola. --host en la línea de comandos tiene prioridad.

El host de destino es un nombre o una dirección IP tal como lo ve el equipo que ejecuta la CLI, sin http:// ni puerto:

Un dispositivo de tu red

Un NAS, un segundo PC o un servidor de consola en tu red local:

192.168.1.20

nas.local

El equipo que ejecuta la CLI debe poder alcanzarlo: prueba con ping 192.168.1.20 y comprueba que el servidor acepta conexiones de otros equipos (no solo de 127.0.0.1).

Docker

Si la CLI se ejecuta directamente en el host de Docker, publica el puerto del servidor (-p 25565:25565) y deja vacío el host de destino.

Si la CLI se ejecuta en su propio contenedor, en la misma red de Docker que tu servidor (por ejemplo como servicio en tu archivo Compose), usa el nombre del contenedor o del servicio del servidor como host de destino (consulta Contenedor Docker):

mc

Sitios web con HTTPS

Los túneles reenvían TCP/UDP sin procesar. Un sitio web con HTTPS mostrará un aviso de certificado, porque el navegador se conecta a <relay>.voidport.net y el certificado está emitido para otro nombre. El HTTP simple y los servidores de juegos no se ven afectados. HTTPS en tu propio dominio lo soluciona.

Contenedor Docker

La CLI también se ejecuta como contenedor junto a tu servidor, por ejemplo en el mismo archivo Compose. No se publica nada en el host: los jugadores se conectan a través del relay. Crea el túnel en el dashboard y pásale su token y el nombre del servicio del servidor:

services:
  mc:
    image: itzg/minecraft-server
    environment:
      EULA: "TRUE"
    volumes:
      - mc-data:/data

  voidport:
    image: ghcr.io/voidmind-io/voidport:latest
    environment:
      VOIDPORT_TOKEN: ${VOIDPORT_TOKEN}
      VOIDPORT_HOST: mc
    depends_on:
      - mc
    restart: unless-stopped

volumes:
  mc-data:

$ VOIDPORT_TOKEN=<token> docker compose up -d

$ docker compose logs voidport

El log muestra la dirección pública. VOIDPORT_TOKEN admite varios tokens separados por comas (p. ej. juego y chat de voz). VOIDPORT_HOST es el nombre del servicio de tu servidor; VOIDPORT_PORT sustituye el puerto local del túnel (solo con un token). VOIDPORT_TOKEN_FILE lee el o los tokens desde un archivo, p. ej. un secreto de Compose en /run/secrets/voidport_token. docker compose down desconecta el túnel limpiamente.

Minecraft Bedrock

Con itzg/minecraft-bedrock-server, crea el túnel con la plantilla de Bedrock. El log de voidport muestra una línea server-udp-ports=…: pon su valor como SERVER_UDP_PORTS en el servicio mc y reinícialo.

SERVER_UDP_PORTS: "<relay IP>:<public port>:19132"

Minecraft sin puerto

Minecraft Java consulta un registro SRV antes de conectarse, así que los jugadores no tienen que escribir el puerto. Ponle un nombre a tu túnel y los jugadores entran con survival.voidport.net en lugar de nbg1.voidport.net:30421.

Define el nombre en la página del túnel en Dirección sin puerto, en el formulario de creación al elegir Minecraft: Java Edition, o desde la CLI:

$ voidport tunnel --preset minecraft-java --address survival

Los nombres tienen de 3 a 32 caracteres (a-z, 0-9, guiones) y se asignan por orden de llegada. Un nombre nuevo puede tardar unos minutos en funcionar en todas partes. El nombre solo funciona en Minecraft Java: no es una dirección web.

Bedrock Edition no consulta registros SRV. Los jugadores de Bedrock siguen necesitando la dirección con el puerto.

Tu propio dominio

Para usar un dominio tuyo, p. ej. play.example.com, crea un registro SRV en tu proveedor de DNS. La página del túnel muestra los valores exactos y tiene un botón Comprobar. Con los valores del ejemplo:

_minecraft._tcp.play.example.com. 300 IN SRV 0 5 30421 nbg1.voidport.net.

Nombre _minecraft._tcp.play (en la zona example.com), prioridad 0, peso 5, el puerto público de tu túnel y como destino el host del relay de tu túnel. Con Cloudflare, el registro debe estar en «Solo DNS». Si el túnel cambia de relay o de puerto, actualiza el registro.

IP reales de jugadores (PROXY protocol)

A través de un túnel, tu servidor ve todas las conexiones llegar desde el equipo que ejecuta la CLI. Con el PROXY protocol activado, el relay antepone la IP y el puerto reales del visitante a cada conexión TCP (PROXY protocol v2), para que los baneos, las whitelists y los logs funcionen con direcciones reales.

Actívalo solo si tu servidor está configurado para esperarlo. Un servidor que no espera la cabecera rechaza todas las conexiones. Solo túneles TCP.

Actívalo en el formulario de creación, en la página del túnel en Ajustes, o con voidport tunnel --proxy-protocol para un túnel nuevo. Un cambio se aplica cuando la CLI se reconecta (reiníciala). Después actívalo en tu servidor:

Paper (config/paper-global.yml)

proxies:
  proxy-protocol: true

Velocity (velocity.toml, [advanced])

haproxy-protocol = true

BungeeCord / Waterfall (config.yml, en listeners)

proxy_protocol: true

nginx

listen 8080 proxy_protocol;

Con Velocity o BungeeCord, actívalo solo en el proxy, no en los servidores que hay detrás. Los servidores Vanilla y Spigot no pueden leer la cabecera: déjalo desactivado. En nginx la dirección está en $proxy_protocol_addr.

HTTPS en tu propio dominio

Sirve un sitio web o una API como https://app.example.com en el puerto estándar 443, con un dominio que sea tuyo. El relay solo lee el nombre de host que pide el navegador (SNI) y reenvía la conexión cifrada sin cambios a tu túnel; nunca ve el contenido. TLS termina en la CLI de VoidPort, con un certificado automático, o en tu propio servidor (Caddy, nginx, Traefik, ...).

1. En el panel, en Dominios, añade el nombre de host y elige quién gestiona el certificado: la CLI de VoidPort (automático) o tu propio servidor.
2. En tu proveedor de DNS, crea el registro TXT _voidport-challenge.app.example.com con el valor indicado y haz clic en Verificar. Mantén el registro TXT: se vuelve a comprobar cada día. El nombre de host pertenece a tu cuenta: una vez verificado, puede pasar de un túnel tuyo a otro sin volver a verificarlo.
3. Asigna el nombre de host a un túnel TCP, en la página Dominios o en la pestaña de ajustes del túnel. Si la CLI gestiona TLS, el destino del túnel es tu servidor HTTP simple (p. ej. 3000); con tu propio servidor, su puerto HTTPS (p. ej. 443).
4. Crea un CNAME de app.example.com al relay del túnel (p. ej. nbg1.voidport.net). Para un dominio raíz, donde no se permite CNAME, usa en su lugar un registro A con la IP del relay.

Detrás de Cloudflare, pon el registro en Solo DNS (nube gris). El proxy naranja termina TLS por sí mismo y nunca llegaría a tu servidor. Solo se pueden usar dominios tuyos, nunca los de VoidPort.

Certificados

Con la CLI de VoidPort no hay nada que hacer: en cuanto el nombre de host está verificado y apunta al relay, la CLI obtiene un certificado de Let's Encrypt y lo renueva (actualiza a la última CLI). Con tu propio servidor: el puerto 80 no se reenvía, así que el desafío HTTP-01 no funciona; usa una de estas opciones:

• TLS-ALPN-01 (automático, a través del túnel): Caddy lo hace por defecto en cuanto HTTP-01 está desactivado. Traefik: un certificate resolver con tlsChallenge.
• DNS-01: funciona en cualquier sitio (certbot, acme.sh, plugins DNS de Caddy/Traefik).

Caddy (Caddyfile)

{
  # port 80 is not reachable through the tunnel
  auto_https disable_redirects
}

app.example.com {
  tls {
    issuer acme {
      disable_http_challenge
    }
  }
  reverse_proxy localhost:3000
}

El PROXY protocol también funciona aquí: si está activado, la conexión empieza con la cabecera antes del handshake TLS (nginx: listen 443 ssl proxy_protocol;). No se admiten HTTP simple en el puerto 80 ni nombres de host comodín.

Ejecutar como servicio

En un servidor, o en un PC que deba mantener el túnel activo sin nadie con sesión iniciada, instala la CLI como servicio del sistema. Arranca con el equipo y se reinicia solo si se detiene.

Linux y macOS

$ sudo voidport service install

Sin nombres, ejecuta todos los túneles que creaste en este equipo con voidport tunnel. Indica nombres para elegir algunos (sudo voidport service install mc), o usa tokens del dashboard: sudo voidport service install --token <token>.

Windows

Abre PowerShell con Ejecutar como administrador:

$ voidport service install --token <token>

Gestionarlo

$ voidport service status

$ voidport service logs -f

$ sudo voidport service update

$ sudo voidport service uninstall

El servicio ejecuta su propia copia de la CLI en una carpeta que solo pueden modificar los administradores. Después de voidport update, ejecuta service update (en Windows, en una terminal de administrador) para que el servicio también use la nueva versión.

El servicio guarda los tokens de los túneles en un archivo que solo pueden leer el servicio y los administradores (/etc/voidport/service.json, en Windows %ProgramData%\VoidPort). No necesita tu inicio de sesión. Vuelve a ejecutar service install para cambiar los túneles. En Linux el servicio usa systemd y se ejecuta como el usuario del sistema voidport; el log está en el journal. En macOS es un daemon de launchd que escribe en /var/log/voidport.log.

Comandos de la CLI

$ voidport connect <token> [<token> ...]

$ voidport login

$ voidport tunnel --preset minecraft-java

$ voidport up [<name> ...]

$ sudo voidport service install [<name> ...]

$ voidport list

$ voidport presets

$ voidport relays

$ voidport status [<name>]

$ voidport delete <name>

$ voidport update

TCP o UDP

¿No sabes cuál elegir? La mayoría de las aplicaciones usan TCP. Minecraft Java usa TCP, Minecraft Bedrock (1.26.50 y posteriores) usa ambos.

Planes y límites

Puertos fijos: tu puerto público no cambia al reconectar, así que los jugadores no necesitan una dirección nueva.

Solución de problemas