Configuração sing-box VLESS Reality 2026: os campos que a maioria dos guias ainda erra

Procure um guia de sing-box Reality e vai encontrar muitos ficheiros de configuração que estavam corretos em 2024. Continuam a ser lidos sem erro, e é esse o problema: nada o avisa de que acabou de construir sobre campos que o projeto tornou obsoletos. Este artigo percorre uma configuração VLESS Reality verificada campo a campo face à documentação atual, e assinala as partes que mudaram discretamente de lugar.

Como referência, a versão face à qual isto foi verificado é o sing-box 1.13.15, lançado a 29 de julho de 2026.

O que o Reality muda de facto

Os proxies convencionais baseados em TLS têm uma fragilidade estrutural: o certificado pertence-lhe. Um censor que inspecione o handshake vê um domínio e um certificado que não correspondem a um site real e popular, e essa discrepância é, em si mesma, o sinal.

A abordagem do Reality consiste em pedir emprestado o handshake de um site de terceiros genuíno. O seu servidor é configurado para apontar para um host externo real, e o tráfego que falha a autenticação é encaminhado para lá. Para um observador, a ligação assemelha-se a uma ligação a esse site, porque em parte é isso mesmo.

É por isto que a configuração tem um bloco handshake. Não é decoração e a sua escolha importa mais do que qualquer outro valor que venha a definir.

Os três campos Reality obrigatórios no servidor

Dentro do objeto tls, o bloco reality exige exatamente três coisas, segundo a documentação:

• handshake (objeto), contendo server e server_port, o site externo ao qual o seu servidor pede emprestado
• private_key (string), que a documentação diz ser gerada por sing-box generate reality-keypair
• short_id (string), descrita como uma string hexadecimal com zero a oito dígitos

Existe também um booleano enabled, e um max_time_difference opcional, que define a diferença de relógio tolerada entre as duas pontas. A documentação nota que a verificação fica desativada quando este campo é deixado vazio. Se o definir, tenha em conta que passa a depender de ambas as máquinas manterem a hora certa.

Gerar as chaves

Há dois valores a gerar antes de escrever seja o que for:

sing-box generate reality-keypair
sing-box generate uuid

O par de chaves imprime uma chave privada e uma chave pública. A chave privada fica no servidor. A chave pública vai para todos os clientes. O UUID é a identidade de utilizador VLESS.

Guarde o par junto e em local seguro no momento em que o gera. A chave pública não é recuperável a partir de um ficheiro de configuração que só guarda a privada, e regenerar o par invalida todos os clientes que já tenha distribuído.

O inbound do servidor

Um inbound VLESS exige type, tag, os campos de escuta e um array users. Cada entrada de utilizador leva um uuid, opcionalmente um name, e opcionalmente um flow. A documentação lista exatamente um valor de flow disponível: 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"
    }
  }
}

Repare no server_name e no server do handshake. São campos separados que normalmente vão conter o mesmo host, e uma discrepância entre eles é uma causa frequente de uma instalação que arranca sem problemas e depois falha no momento da ligação.

A parte que a maioria dos guias erra

Aqui está a diferença entre uma configuração de 2024 e uma atual. Estes três campos do inbound ficaram obsoletos na versão 1.11.0:

• sniff
• sniff_timeout
• domain_strategy

Saíram do inbound e passaram a ser ações de regras de rota. O guia de migração dá as equivalências diretas:

{
  "route": {
    "rules": [
      { "inbound": "vless-in", "action": "sniff", "timeout": "1s" },
      { "inbound": "vless-in", "action": "resolve", "strategy": "prefer_ipv4" }
    ]
  }
}

Ou seja, "sniff": true passa a ser uma action de sniff, o sniff_timeout passa a ser o timeout dessa ação, e o domain_strategy passa a ser uma action de resolve com uma strategy.

Para ser rigoroso quanto ao que está em jogo: a documentação marca-os como obsoletos e não anuncia uma data de remoção. Hoje nada se parte. Mas uma configuração que ainda os contenha está escrita contra uma interface de que o projeto se afastou, e isso vale a pena saber quando está a escolher que tutorial seguir.

Dois campos relacionados, sniff_override_destination e udp_disable_domain_unmapping, estão também marcados como obsoletos na documentação atual dos campos de escuta.

O lado do cliente

O cliente precisa de menos do que o servidor. O Reality no cliente exige:

• public_key, a contraparte da chave privada do servidor
• short_id, que tem de corresponder a um valor que o servidor aceite

O objeto utls fica ao lado, com enabled e fingerprint. Os valores de fingerprint documentados como aceites são chrome, firefox, edge, safari, 360, qq, ios, android, random e randomized. A documentação indica que é usado o fingerprint do Chrome quando o campo está vazio.

Um ponto de honestidade aqui, porque os guias tendem a afirmar o contrário: a documentação do sing-box apresenta o utls como uma opção TLS independente e não afirma que o Reality o exija. A maioria das configurações de cliente ativa-o de qualquer forma.

Escolher o host de handshake

Nenhum valor de configuração afeta mais o seu resultado, e nenhum guia o pode escolher por si, porque a resposta certa depende de onde está o seu servidor e de onde estão os seus clientes.

As propriedades que contam:

• Deve ser um host que suporte genuinamente TLS 1.3 na porta para a qual aponta
• Deve ser tráfego plausível a partir da localização de rede do seu servidor
• Não deve ser um site que esteja ele próprio bloqueado no país a partir do qual se liga, o que anularia por completo o objetivo
• Não deve ser um site que controle, já que a ideia é precisamente ser tráfego real de outra pessoa

Um conselho repetido com frequência é escolher algo grande e genérico. Cuidado com esse raciocínio: um host que todos os tutoriais recomendam é, por definição, um host que aparece em todas as configurações, e a popularidade dentro da comunidade de proxies não é a mesma coisa que passar despercebido.

Antes de concluir que funciona

Duas verificações que vale a pena fazer e que vão além de "o cliente ligou-se".

Confirme que o fallback se comporta. Aponte um browser simples para o endereço e a porta do seu servidor. O que deve ver é o site de handshake, não um erro nem um timeout. Se obtiver outra coisa, a passagem não está a fazer o seu trabalho e a instalação é mais visível do que um proxy vulgar.

Verifique os dois relógios. Se definiu max_time_difference, o desvio em qualquer das máquinas produz falhas que parecem problemas de autenticação e o levam a andar a editar chaves que nunca estiveram erradas.

Se ainda está a decidir entre motores em vez de configurar um, os prós e contras estão expostos na nossa comparação sing-box contra Xray.

A versão curta

Três campos Reality obrigatórios no servidor: handshake, private_key, short_id. Dois no cliente: public_key, short_id. As chaves vêm de sing-box generate reality-keypair. E se o guia que está a ler coloca sniff ou domain_strategy dentro do inbound, é anterior à versão 1.11 e o equivalente atual é uma ação de regra de rota.

Os nomes de campos, requisitos e obsolescências deste artigo foram retirados da documentação oficial e do guia de migração do sing-box, verificados face à versão 1.13.15 a 30 de julho de 2026. As interfaces de configuração mudam entre versões, por isso confirme na documentação da versão que estiver a executar. Contornar a censura é restringido ou ilegal em algumas jurisdições; verifique o que se aplica onde está.