Gerador de configuração VLESS + REALITY
Indique o endereço do seu servidor e o site de que o REALITY deve emprestar o handshake TLS. O gerador cria o par de chaves X25519, o UUID e o short ID, e escreve as configurações de servidor e cliente para Xray-core ou sing-box, um link vless:// para importar no v2rayN, v2rayNG, Hiddify ou Shadowrocket, e os comandos de instalação. As chaves nunca saem do seu navegador.
Tudo acontece no seu navegador: chaves, UUID e configurações são gerados localmente e não são enviados para lado nenhum.
O IP público do seu VPS (ou um domínio que aponte para ele). Usado na configuração do cliente e no link.
443 é a norma: o REALITY imita HTTPS.
Um site de terceiros com TLS 1.3 e HTTP/2, acessível aos seus clientes. Veja a lista de verificação abaixo da ferramenta.
A impressão TLS que o cliente imita. chrome é a escolha habitual.
A chave privada vai apenas para o servidor. A pública vai para cada cliente.
Hexadecimal, comprimento par, até 16 caracteres.
- As chaves faltam ou são inválidas (32 bytes, base64url, 43 caracteres). Gere um par ou cole o seu.
Link de partilha vless://
vless://@203.0.113.10:443?encryption=none&flow=xtls-rprx-vision&security=reality&sni=www.example.com&fp=chrome&pbk=&sid=&type=tcp&headerType=none#my-reality
Importe-o no v2rayN, v2rayNG, Hiddify, Streisand ou Shadowrocket, ou leia o código QR.
{
"log": {
"loglevel": "warning"
},
"inbounds": [
{
"listen": "0.0.0.0",
"port": 443,
"protocol": "vless",
"settings": {
"clients": [
{
"id": "",
"flow": "xtls-rprx-vision",
"email": "my-reality"
}
],
"decryption": "none"
},
"streamSettings": {
"network": "tcp",
"security": "reality",
"realitySettings": {
"show": false,
"target": "www.example.com:443",
"xver": 0,
"serverNames": [
"www.example.com"
],
"privateKey": "",
"shortIds": [
""
]
}
},
"sniffing": {
"enabled": true,
"destOverride": [
"http",
"tls",
"quic"
],
"routeOnly": true
}
}
],
"outbounds": [
{
"protocol": "freedom",
"tag": "direct"
},
{
"protocol": "blackhole",
"tag": "block"
}
]
}{
"log": {
"loglevel": "warning"
},
"inbounds": [
{
"listen": "127.0.0.1",
"port": 10808,
"protocol": "socks",
"settings": {
"udp": true
}
},
{
"listen": "127.0.0.1",
"port": 10809,
"protocol": "http"
}
],
"outbounds": [
{
"protocol": "vless",
"tag": "proxy",
"settings": {
"vnext": [
{
"address": "203.0.113.10",
"port": 443,
"users": [
{
"id": "",
"flow": "xtls-rprx-vision",
"encryption": "none"
}
]
}
]
},
"streamSettings": {
"network": "tcp",
"security": "reality",
"realitySettings": {
"serverName": "www.example.com",
"fingerprint": "chrome",
"publicKey": "",
"shortId": "",
"spiderX": "/"
}
}
},
{
"protocol": "freedom",
"tag": "direct"
}
]
}# Instalar o Xray-core com o script oficial (serviço systemd incluído)
bash -c "$(curl -L https://github.com/XTLS/Xray-install/raw/main/install-release.sh)" @ install
# Opcional: confirmar que a chave pública corresponde à privada
xray x25519 -i ""
# Verificar que o destino responde em TLS 1.3 e HTTP/2
xray tls ping www.example.com
# Abrir a porta
sudo ufw allow 443/tcp
# Colar a configuração do servidor, testá-la e iniciar o serviço
sudo nano /usr/local/etc/xray/config.json
xray run -test -c /usr/local/etc/xray/config.json
sudo systemctl restart xray && sudo systemctl enable xray
# Acompanhar o registo enquanto o primeiro cliente se liga
sudo journalctl -u xray -f
O REALITY precisa de um servidor que controla
Um servidor REALITY é um VPS com IP público e a porta 443 livre, mais nada. O VPS de entrada da Contabo inclui IPv4 público, acesso root e muito tráfego, e pode escolher o datacenter mais próximo dos seus utilizadores.
Link de afiliado: podemos receber uma comissão, sem custo extra para si. O gerador continua gratuito e não depende disso.
O que faz cada valor e porque têm de coincidir
O REALITY substitui o certificado TLS de que normalmente precisaria. O seu servidor responde na porta 443 como o site real escolhido como destino: um censor que se liga sem as credenciais certas recebe o handshake e as páginas do site autêntico, reencaminhados pelo seu servidor. Só um cliente que conhece a chave pública do servidor e um short ID válido conclui o handshake do proxy.
Por isso, quatro valores têm de coincidir nos dois lados. A chave privada fica no servidor e a pública vai para cada cliente. O site de destino tem de aparecer como destino (target, ou dest em guias antigos; handshake.server no sing-box) e nos nomes de servidor aceites, e o cliente envia-o como SNI. O short ID enviado pelo cliente tem de estar na lista do servidor. O UUID identifica o utilizador, e xtls-rprx-vision tem de estar definido nos dois lados, senão a ligação é recusada.
As configurações abaixo usam apenas campos documentados: sem opções sniff obsoletas do sing-box no inbound, sem transportes a mais. Acrescente regras de encaminhamento ou mais utilizadores quando o túnel básico funcionar.
Escolher o site de destino: lista de verificação
O destino conta mais do que qualquer outro campo, e nenhuma ferramenta o pode escolher por si. Estas são as propriedades a verificar antes de decidir.
| Verificação | Porque importa | Como verificar |
|---|---|---|
| TLS 1.3 e HTTP/2 | O REALITY precisa de um handshake TLS 1.3 para imitar | xray tls ping <host>, ou curl -I --tlsv1.3 --http2 |
| Não bloqueado onde estão os seus clientes | Um destino bloqueado faz o seu servidor parecer um site bloqueado | Abra-o a partir da rede do cliente, sem proxy |
| Plausível a partir da rede do servidor | Um VPS pequeno a servir a página inicial de um gigante dá nas vistas; um host do mesmo fornecedor ou região passa mais despercebido | Compare a localização IP do destino com o datacenter do VPS |
| Sem redirecionamento para outro domínio | O SNI tem de corresponder ao certificado que o destino serve de facto | curl -sI https://<host> e procure um cabeçalho Location |
| Não é o seu próprio domínio | O objetivo é parecer tráfego real de outra pessoa | Escolha um site de terceiros que não controla |
Contornar restrições de rede é restrito ou ilegal em algumas jurisdições. Verifique o que se aplica onde você e os seus utilizadores se encontram.