Loslegen mit VoidPort

Schnellstart

Bring deinen lokalen Server in unter 2 Minuten online.

1. 1

   Konto erstellen

   Registriere dich unter voidport.app/register und wähle einen Tarif.

2. 2

   Tunnel im Dashboard erstellen

   Geh zu Dashboard > Tunnels > Tunnel erstellen. Wähle, was du hostest, und eine Region.

Das war’s. Dein Server ist jetzt unter der öffentlichen Adresse erreichbar, die im Dashboard steht.

Installation

Unter Windows legt der Installer voidport.exe in %LOCALAPPDATA%\VoidPort ab und fügt es deinem PATH hinzu. Unter macOS und Linux landet es in /usr/local/bin, ohne Root oder sudo in ~/.local/bin.

Manueller Download

Binaries direkt herunterladen:

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

Installation prüfen

$ voidport --version

Tunnel erstellen

Im Dashboard

1. Melde dich in deinem Dashboard an
2. Klick auf „Tunnel erstellen“
3. Wähle, was du hostest, oder „Eigener Port“ mit TCP, UDP oder beidem
4. Gib ihm einen Namen (z. B. „minecraft“) und wähle eine Region (Nürnberg, Helsinki, Ashburn oder Hillsboro)
5. Läuft der Server auf einem anderen Gerät, gib dessen Ziel-Host an
6. Klick auf „Tunnel erstellen“, starte die CLI und klick dann auf „Verbindung testen“

Nach dem Erstellen zeigt dir das Dashboard den Token des Tunnels und den Befehl zum Starten. Beides findest du jederzeit auf der Seite des Tunnels. Halte den Token geheim.

Starten

Führ das auf dem Rechner aus, auf dem dein Server läuft:

$ voidport connect <token>

Nur dieses eine Mal auf einen anderen lokalen Port weiterleiten:

$ voidport connect <token> --port 25566

Mehrere Tunnel in einem Fenster starten, zum Beispiel Spiel und Voice-Chat:

$ voidport connect <token1> <token2>

Mit der CLI

Du kannst Tunnel auch im Terminal erstellen und starten. Dafür brauchst du einmalig voidport login.

$ voidport login

$ voidport tunnel --preset minecraft-java

voidport up startet alle auf diesem Rechner gespeicherten Tunnel, voidport list zeigt sie an.

Andere Geräte & Docker

Standardmäßig leitet die CLI auf den Rechner weiter, auf dem sie läuft. Läuft dein Server woanders, setz den Ziel-Host des Tunnels: im Formular beim Erstellen, auf der Seite des Tunnels unter Einstellungen oder mit voidport tunnel --host. Der Startbefehl bleibt voidport connect <token>; die CLI übernimmt den Ziel-Host von selbst. --host auf der Kommandozeile hat Vorrang.

Der Ziel-Host ist ein Name oder eine IP-Adresse, wie sie der Rechner mit der CLI sieht, ohne http:// und ohne Port:

Ein Gerät in deinem Netzwerk

Ein NAS, ein zweiter PC oder ein Konsolen-Server in deinem LAN:

192.168.1.20

nas.local

Der Rechner mit der CLI muss es erreichen können: Teste mit ping 192.168.1.20 und prüfe, ob der Server Verbindungen von anderen Geräten erlaubt (nicht nur von 127.0.0.1).

Docker

Läuft die CLI direkt auf dem Docker-Host, veröffentliche den Port des Servers (-p 25565:25565) und lass den Ziel-Host leer.

Läuft die CLI in einem eigenen Container im selben Docker-Netzwerk wie dein Server (zum Beispiel als Service in deiner Compose-Datei), nimm den Container- oder Service-Namen des Servers als Ziel-Host (siehe Docker-Container):

mc

Websites über HTTPS

Tunnel leiten reines TCP/UDP weiter. Eine Website mit HTTPS zeigt eine Zertifikatswarnung, weil sich der Browser mit <relay>.voidport.net verbindet und das Zertifikat für einen anderen Namen ausgestellt ist. Normales HTTP und Gameserver sind nicht betroffen. HTTPS auf deiner eigenen Domain löst das.

Docker-Container

Die CLI läuft auch als Container neben deinem Server, zum Beispiel in derselben Compose-Datei. Auf dem Host wird nichts veröffentlicht: Spieler verbinden sich über das Relay. Erstell den Tunnel im Dashboard und übergib dann seinen Token und den Service-Namen des Servers:

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

Das Log zeigt die öffentliche Adresse. VOIDPORT_TOKEN nimmt mehrere Tokens, durch Kommas getrennt (z. B. Spiel und Voice-Chat). VOIDPORT_HOST ist der Service-Name deines Servers; VOIDPORT_PORT überschreibt den lokalen Port des Tunnels (nur bei einem Token). VOIDPORT_TOKEN_FILE liest den oder die Tokens stattdessen aus einer Datei, z. B. einem Compose-Secret unter /run/secrets/voidport_token. docker compose down trennt den Tunnel sauber.

Minecraft Bedrock

Mit itzg/minecraft-bedrock-server erstellst du den Tunnel mit der Bedrock-Vorlage. Das voidport-Log zeigt eine Zeile server-udp-ports=…: Setz ihren Wert als SERVER_UDP_PORTS beim Service mc und starte ihn neu.

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

Minecraft ohne Port

Minecraft Java fragt vor dem Verbinden einen SRV-Record ab, deshalb müssen Spieler keinen Port eintippen. Gib deinem Tunnel einen Namen, und Spieler verbinden sich mit survival.voidport.net statt nbg1.voidport.net:30421.

Den Namen legst du auf der Seite des Tunnels unter Adresse ohne Port fest, im Formular beim Erstellen, wenn du Minecraft: Java Edition wählst, oder mit der CLI:

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

Namen haben 3–32 Zeichen (a–z, 0–9, Bindestriche), wer zuerst kommt, mahlt zuerst. Ein neuer Name kann ein paar Minuten brauchen, bis er überall funktioniert. Der Name funktioniert nur in Minecraft Java, er ist keine Website-Adresse.

Die Bedrock Edition fragt keine SRV-Records ab. Bedrock-Spieler brauchen weiterhin die Adresse mit Port.

Deine eigene Domain

Für eine eigene Domain, z. B. play.example.com, legst du bei deinem DNS-Anbieter einen SRV-Record an. Die Seite des Tunnels zeigt die genauen Werte und hat einen Prüfen-Button. Mit den Beispielwerten:

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

Name _minecraft._tcp.play (in der Zone example.com), Priorität 0, Gewicht 5, der öffentliche Port deines Tunnels, Ziel ist der Relay-Host deines Tunnels. Bei Cloudflare muss der Record auf „Nur DNS“ stehen. Zieht der Tunnel auf ein anderes Relay oder einen anderen Port um, pass den Record an.

Echte Spieler-IPs (PROXY-Protokoll)

Über einen Tunnel sieht dein Server jede Verbindung vom Rechner mit der CLI kommen. Mit eingeschaltetem PROXY-Protokoll setzt das Relay die echte IP und den Port des Besuchers vor jede TCP-Verbindung (PROXY protocol v2), damit Bans, Whitelists und Logs mit echten Adressen funktionieren.

Schalt es nur ein, wenn dein Server dafür eingerichtet ist. Ein Server, der den Header nicht erwartet, lehnt jede Verbindung ab. Nur für TCP-Tunnel.

Schalt es im Formular beim Erstellen ein, auf der Seite des Tunnels unter Einstellungen oder mit voidport tunnel --proxy-protocol für einen neuen Tunnel. Eine Änderung greift, sobald sich die CLI neu verbindet (starte sie neu). Aktiviere es dann in deinem Server:

Paper (config/paper-global.yml)

proxies:
  proxy-protocol: true

Velocity (velocity.toml, [advanced])

haproxy-protocol = true

BungeeCord / Waterfall (config.yml, unter listeners)

proxy_protocol: true

nginx

listen 8080 proxy_protocol;

Bei Velocity oder BungeeCord aktivierst du es nur auf dem Proxy, nicht auf den Servern dahinter. Vanilla- und Spigot-Server können den Header nicht lesen: Lass es dort aus. In nginx steht die Adresse in $proxy_protocol_addr.

HTTPS auf deiner eigenen Domain

Stell eine Website oder API als https://app.example.com auf dem Standardport 443 bereit, mit einer Domain, die dir gehört. Das Relay liest nur den Hostnamen, den der Browser anfragt (SNI), und leitet die verschlüsselte Verbindung unverändert an deinen Tunnel weiter; den Inhalt sieht es nie. TLS endet entweder in der VoidPort-CLI, mit einem automatischen Zertifikat, oder auf deinem eigenen Server (Caddy, nginx, Traefik, ...).

1. Füg im Dashboard unter Domains den Hostnamen hinzu und wähl, wer sich um das Zertifikat kümmert: die VoidPort-CLI (automatisch) oder dein eigener Server.
2. Leg bei deinem DNS-Anbieter den TXT-Record _voidport-challenge.app.example.com mit dem angezeigten Wert an und klick auf Bestätigen. Lass den TXT-Record stehen: Er wird jeden Tag erneut geprüft. Der Hostname gehört zu deinem Konto: Einmal bestätigt, kann er ohne neue Bestätigung zwischen deinen Tunneln wechseln.
3. Weis den Hostnamen einem TCP-Tunnel zu, auf der Domains-Seite oder im Einstellungen-Tab des Tunnels. Wenn die CLI TLS übernimmt, ist das Ziel des Tunnels dein HTTP-Server (z. B. 3000); mit eigenem Server dessen HTTPS-Port (z. B. 443).
4. Leg einen CNAME von app.example.com auf das Relay des Tunnels an (z. B. nbg1.voidport.net). Für eine Root-Domain, bei der kein CNAME erlaubt ist, nimm stattdessen einen A-Record mit der IP des Relays.

Hinter Cloudflare stellst du den Record auf Nur DNS (graue Wolke). Der orange Proxy terminiert TLS selbst und würde deinen Server nie erreichen. Nur Domains, die dir gehören, sind möglich, nie die von VoidPort.

Zertifikate

Mit der VoidPort-CLI ist nichts zu tun: Sobald der Hostname bestätigt ist und auf das Relay zeigt, holt die CLI ein Zertifikat von Let's Encrypt und erneuert es (aktualisier dafür auf die neueste CLI). Mit eigenem Server: Port 80 wird nicht weitergeleitet, die HTTP-01-Challenge funktioniert also nicht; nimm eine dieser Varianten:

• TLS-ALPN-01 (automatisch, durch den Tunnel): Caddy macht das standardmäßig, sobald HTTP-01 aus ist. Traefik: ein Certificate Resolver mit tlsChallenge.
• DNS-01: funktioniert überall (certbot, acme.sh, DNS-Plugins für 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
}

Das PROXY-Protokoll funktioniert auch hier: Ist es eingeschaltet, beginnt die Verbindung vor dem TLS-Handshake mit dem Header (nginx: listen 443 ssl proxy_protocol;). Reines HTTP auf Port 80 und Wildcard-Hostnamen werden nicht unterstützt.

Als Dienst ausführen

Auf einem Server oder einem PC, der den Tunnel auch ohne angemeldeten Benutzer offen halten soll, installierst du die CLI als Systemdienst. Er startet mit dem Rechner und startet sich selbst neu, wenn er stoppt.

Linux und macOS

$ sudo voidport service install

Ohne Namen startet er alle Tunnel, die du auf diesem Rechner mit voidport tunnel erstellt hast. Gib Namen an, um einzelne auszuwählen (sudo voidport service install mc), oder nimm Tokens aus dem Dashboard: sudo voidport service install --token <token>.

Windows

Öffne PowerShell mit Als Administrator ausführen:

$ voidport service install --token <token>

Verwalten

$ voidport service status

$ voidport service logs -f

$ sudo voidport service update

$ sudo voidport service uninstall

Der Dienst nutzt eine eigene Kopie der CLI in einem Ordner, den nur Administratoren ändern können. Führ nach voidport update auch service update aus (unter Windows in einer Administrator-Shell), damit der Dienst ebenfalls die neue Version nutzt.

Der Dienst speichert die Tunnel-Tokens in einer Datei, die nur der Dienst und Administratoren lesen können (/etc/voidport/service.json, unter Windows %ProgramData%\VoidPort). Deine Anmeldung braucht er nicht. Führ service install erneut aus, um die Tunnel zu ändern. Unter Linux nutzt der Dienst systemd und läuft als Systembenutzer voidport; das Log steht im Journal. Unter macOS ist er ein launchd-Daemon und schreibt nach /var/log/voidport.log.

CLI-Befehle

$ 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 oder UDP

Unsicher, was du nehmen sollst? Die meisten Anwendungen nutzen TCP. Minecraft Java nutzt TCP, Minecraft Bedrock (ab 1.26.50) nutzt beides.

Tarife & Limits

Feste Ports: Dein öffentlicher Port bleibt auch nach einem Neuverbinden gleich, Spieler brauchen also keine neue Adresse.

Fehlerbehebung