Suchen Sie nach einer sing-box Reality Anleitung, und Sie finden jede Menge Konfigurationsdateien, die 2024 richtig waren. Sie werden weiterhin eingelesen, und genau das ist das Problem: nichts warnt Sie davor, dass Sie gerade auf Feldern aufgebaut haben, die das Projekt als veraltet markiert hat. Dieser Text geht ein VLESS Reality Setup Feld für Feld gegen die aktuelle Dokumentation durch und zeigt, welche Teile sich still und leise verschoben haben.
Zur Einordnung: geprüft wurde gegen sing-box 1.13.15, veröffentlicht am 29. Juli 2026.
Was Reality tatsächlich verändert
Klassische TLS-basierte Proxys haben eine strukturelle Schwäche: das Zertifikat gehört Ihnen. Wer den Handshake untersucht, sieht eine Domain und ein Zertifikat, die zu keiner echten, populären Website passen, und dieser Widerspruch ist selbst schon das Signal.
Der Ansatz von Reality besteht darin, sich den Handshake einer echten fremden Seite zu leihen. Ihr Server wird so konfiguriert, dass er auf einen echten externen Host zeigt, und Datenverkehr, der die Authentifizierung nicht besteht, wird dorthin durchgereicht. Für einen Beobachter sieht die Verbindung aus wie eine Verbindung zu dieser Seite, denn zum Teil ist sie das auch.
Deshalb hat die Konfiguration einen handshake-Block. Er ist keine Zierde, und seine Wahl wiegt schwerer als jeder andere Wert, den Sie setzen werden.
Die drei erforderlichen Reality-Felder auf dem Server
Innerhalb des tls-Objekts verlangt der reality-Block laut Dokumentation genau drei Dinge:
handshake(Objekt), enthältserverundserver_port, also die externe Seite, von der sich Ihr Server borgtprivate_key(String), der laut Dokumentation mitsing-box generate reality-keypairerzeugt wirdshort_id(String), beschrieben als hexadezimale Zeichenkette mit null bis acht Stellen
Dazu kommt ein enabled-Boolean sowie ein optionales max_time_difference, das die tolerierte Zeitabweichung zwischen beiden Enden festlegt. Die Dokumentation merkt an, dass die Prüfung deaktiviert ist, wenn das Feld leer bleibt. Wenn Sie es setzen, denken Sie daran, dass Sie damit darauf angewiesen sind, dass beide Maschinen die Uhrzeit korrekt halten.
Die Schlüssel erzeugen
Zwei Werte müssen erzeugt werden, bevor Sie irgendetwas schreiben:
sing-box generate reality-keypair
sing-box generate uuid
Das Keypair gibt einen Private Key und einen Public Key aus. Der Private Key bleibt auf dem Server. Der Public Key geht an jeden Client. Die UUID ist die VLESS-Benutzeridentität.
Bewahren Sie das Paar bei der Erzeugung gemeinsam an einem sicheren Ort auf. Der Public Key lässt sich nicht aus einer Konfigurationsdatei rekonstruieren, die nur den privaten Teil speichert, und eine Neuerzeugung des Paares entwertet jeden Client, den Sie bereits ausgegeben haben.
Der Server-Inbound
Ein VLESS-Inbound benötigt type, tag, die Listen-Felder und ein users-Array. Jeder Benutzereintrag nimmt eine uuid, optional einen name und optional einen flow. Die Dokumentation nennt genau einen verfügbaren Flow-Wert: xtls-rprx-vision.
{
"type": "vless",
"tag": "vless-in",
"listen": "::",
"listen_port": 443,
"users": [
{
"name": "me",
"uuid": "PASTE-YOUR-GENERATED-UUID",
"flow": "xtls-rprx-vision"
}
],
"tls": {
"enabled": true,
"server_name": "your-handshake-host.example",
"reality": {
"enabled": true,
"handshake": {
"server": "your-handshake-host.example",
"server_port": 443
},
"private_key": "PASTE-YOUR-PRIVATE-KEY",
"short_id": "0123abcd"
}
}
}
Beachten Sie server_name und den server im Handshake. Das sind getrennte Felder, die normalerweise denselben Host enthalten, und eine Abweichung zwischen ihnen ist eine häufige Ursache für ein Setup, das sauber baut und dann beim Verbindungsaufbau scheitert.
Der Teil, den die meisten Anleitungen falsch machen
Hier liegt der Unterschied zwischen einer Konfiguration von 2024 und einer aktuellen. Diese drei Inbound-Felder wurden in Version 1.11.0 als veraltet markiert:
sniffsniff_timeoutdomain_strategy
Sie sind aus dem Inbound herausgewandert und zu Route-Rule-Actions geworden. Der Migrationsleitfaden nennt die direkten Entsprechungen:
{
"route": {
"rules": [
{ "inbound": "vless-in", "action": "sniff", "timeout": "1s" },
{ "inbound": "vless-in", "action": "resolve", "strategy": "prefer_ipv4" }
]
}
}
Aus "sniff": true wird also eine action vom Typ sniff, aus sniff_timeout wird das timeout dieser Action, und aus domain_strategy wird eine action vom Typ resolve mit einer strategy.
Um bei den Konsequenzen genau zu bleiben: die Dokumentation markiert diese Felder als veraltet und kündigt kein Entfernungsdatum an. Heute geht dadurch nichts kaputt. Aber eine Konfiguration, die sie weiterhin mitschleppt, ist gegen eine Schnittstelle geschrieben, von der sich das Projekt abgewandt hat, und das ist es wert zu wissen, wenn Sie sich für ein Tutorial entscheiden.
Zwei verwandte Felder, sniff_override_destination und udp_disable_domain_unmapping, sind in der aktuellen Dokumentation der Listen-Felder ebenfalls als veraltet markiert.
Die Client-Seite
Der Client braucht weniger als der Server. Reality verlangt clientseitig:
public_key, das Gegenstück zum privaten Schlüssel des Serversshort_id, die zu einem Wert passen muss, den der Server akzeptiert
Daneben steht das utls-Objekt mit enabled und fingerprint. Dokumentierte akzeptierte Fingerprint-Werte sind chrome, firefox, edge, safari, 360, qq, ios, android, random und randomized. Die Dokumentation gibt an, dass der Chrome-Fingerprint verwendet wird, wenn das Feld leer ist.
Ein Punkt der Ehrlichkeit an dieser Stelle, weil Anleitungen gern das Gegenteil behaupten: die sing-box Dokumentation führt utls als eigenständige TLS-Option und sagt nicht, dass Reality es voraussetzt. Die meisten Client-Konfigurationen aktivieren es trotzdem.
Die Wahl des Handshake-Hosts
Kein Konfigurationswert beeinflusst Ihr Ergebnis stärker, und keine Anleitung kann ihn für Sie auswählen, weil die richtige Antwort davon abhängt, wo Ihr Server steht und wo Ihre Clients sind.
Die Eigenschaften, auf die es ankommt:
- Es sollte ein Host sein, der auf dem angesteuerten Port tatsächlich TLS 1.3 unterstützt
- Der Datenverkehr sollte vom Netzwerkstandort Ihres Servers aus plausibel wirken
- Es sollte keine Seite sein, die im Land, aus dem Sie sich verbinden, selbst blockiert ist, denn das würde den Zweck vollständig zunichtemachen
- Es sollte keine Seite sein, die Sie kontrollieren, denn der Sinn liegt darin, dass es der echte Datenverkehr von jemand anderem ist
Ein häufig wiederholter Ratschlag lautet, etwas Großes und Generisches zu wählen. Seien Sie mit dieser Begründung vorsichtig: ein Host, den jedes Tutorial empfiehlt, ist per Definition ein Host, der in jeder Konfiguration auftaucht, und Beliebtheit innerhalb der Proxy-Community ist nicht dasselbe wie Unauffälligkeit.
Bevor Sie es für funktionierend erklären
Zwei Prüfungen, die sich lohnen und über "der Client hat sich verbunden" hinausgehen.
Prüfen Sie, ob der Fallback sich richtig verhält. Richten Sie einen ganz normalen Browser auf Adresse und Port Ihres Servers. Zu sehen sein sollte die Handshake-Seite, kein Fehler und kein Timeout. Wenn etwas anderes erscheint, macht der Passthrough seinen Job nicht, und das Setup fällt stärker auf als ein gewöhnlicher Proxy.
Prüfen Sie beide Uhren. Wenn Sie max_time_difference gesetzt haben, erzeugt eine Abweichung auf einer der beiden Maschinen Fehler, die wie Authentifizierungsprobleme aussehen und Sie dazu bringen, an Schlüsseln herumzueditieren, die nie falsch waren.
Wenn Sie sich noch zwischen den Engines entscheiden, statt eine zu konfigurieren: die Abwägungen stehen in unserem Vergleich sing-box gegen Xray.
Die Kurzfassung
Drei erforderliche Reality-Felder auf dem Server: handshake, private_key, short_id. Zwei auf dem Client: public_key, short_id. Die Schlüssel kommen von sing-box generate reality-keypair. Und wenn die Anleitung, die Sie gerade lesen, sniff oder domain_strategy in den Inbound setzt, stammt sie aus der Zeit vor Version 1.11, und die aktuelle Entsprechung ist eine Route-Rule-Action.
Feldnamen, Anforderungen und Deprecations in diesem Artikel stammen aus der offiziellen sing-box Dokumentation und dem Migrationsleitfaden, geprüft gegen Release 1.13.15 am 30. Juli 2026. Konfigurationsschnittstellen ändern sich zwischen Versionen, prüfen Sie daher gegen die Dokumentation des Releases, das Sie einsetzen. Das Umgehen von Zensur ist in manchen Rechtsordnungen eingeschränkt oder rechtswidrig; prüfen Sie, was bei Ihnen gilt.
★ Nürnberger DSGVO-Rechenzentrum · ✓ Dedizierte IPv4 inklusive · 200+ Mbps garantiert
Ein VPS, den du komplett kontrollierst, für Tunneling & Verschleierung → ContaboRoot-Zugriff · jeden Port öffnen · deinen eigenen Stack betreiben→
