v2rayN com o core sing-box (2026): o que muda e a armadilha do DNS

Divulgação de afiliação - este artigo contém uma ligação de afiliado da Contabo. Se encomendar um VPS através dela, recebemos uma comissão sem custo adicional para si. Tudo o que se segue foi retirado do código-fonte do v2rayN, da sua wiki oficial e das páginas de lançamento dos projetos, verificado a 2026-08-09. Os números de versão e os nomes dos campos de configuração mudam com frequência; confirme-os na documentação atual antes de confiar neles.

Resposta curta: mude o v2rayN para o core sing-box apenas se precisar de TUIC, AnyTLS ou Naive - são estes os três protocolos que o core Xray não trata. O Hysteria2 não é um deles, e o Vision e o REALITY funcionam bem em sing-box. A mudança é uma única definição, mas altera silenciosamente o significado dos campos de DNS, que é de onde vem a maioria das configurações avariadas. Se ainda está a escolher entre os dois motores em vez de mudar, comece pela nossa comparação sing-box vs Xray.

Que cores o v2rayN consegue realmente conduzir

A wiki lista onze cores suportados em quatro famílias: a família V2Ray (Xray, v2fly), a família Clash (mihomo), a família sing_box e os independentes, como hysteria2, naiveproxy, tuic, juicity, brook, overtls e shadowquic.

Essa lista é fácil de interpretar mal. No código, apenas dois cores atuam como core principal para o qual o v2rayN gera uma configuração: Xray e sing_box. A página de DNS da wiki diz exatamente o mesmo. Os restantes são usados através de um ficheiro de configuração personalizado - o utilizador fornece a configuração e o v2rayN executa o binário.

Os pacotes para Windows já incluem os binários Xray, sing-box e mihomo dentro do zip. Os outros cores é o utilizador que os descarrega e coloca em bin.

Fazer a mudança

Definições → Tipo de core (Core Type Settings).

A ordem de resolução importa mais do que a própria definição. No arranque, o v2rayN lê primeiro o tipo de core registado no perfil de servidor atual; só se esse estiver vazio é que recorre ao tipo de core global. Na prática, isso significa que pode deixar toda a sua lista em Xray e passar um único nó TUIC para sing-box, sem mexer em mais nada.

Duas tomadas de parede RJ45 cor de creme montadas num painel escuro, com quatro cabos Ethernet brancos ligados através de capas de conector azuis e roxas; um LED vermelho brilha na tomada superior e o chão ao fundo é cinzento-claro.

O que exige genuinamente sing-box: três protocolos

Isto não precisa de ser discutido, porque é o v2rayN que o calcula. O código define os protocolos que cada core suporta e depois deriva o conjunto exclusivo do sing-box como a diferença entre os dois:

Core	Protocolos suportados
Xray	VMess, VLESS, Shadowsocks, Trojan, Hysteria2, WireGuard, SOCKS, HTTP
sing-box	VMess, VLESS, Shadowsocks, Trojan, Hysteria2, TUIC, AnyTLS, Naive, WireGuard, SOCKS, HTTP

Portanto, a resposta é TUIC, AnyTLS e Naive. Mais nada.

Vale a pena corrigir duas convicções com que se vai deparar em tópicos de fóruns, porque ambas são contrariadas pelo código-fonte:

«O Hysteria2 precisa de sing-box.» Não precisa - o Hysteria2 está em ambas as listas, logo o core Xray trata dele. Existem issues no rastreador a relatar problemas práticos com o Hysteria2 em Xray, mas um bug reportado não é uma capacidade em falta.
«O sing-box não consegue fazer Vision nem REALITY no v2rayN.» Consegue. O construtor de outbounds sing-box emite o flow Vision para VLESS e escreve o bloco REALITY (chave pública, short ID) mais a impressão digital uTLS. A variante xtls-rprx-vision-udp443 é normalizada para o simples xtls-rprx-vision.

Existe uma limitação de encadeamento documentada, mas que recai sobre o outro core: com cadeias de proxy, os nós que usam Xray não podem usar TUIC nem AnyTLS como proxy de entrada ou de saída.

A armadilha do DNS - a parte que realmente avaria as configurações

Se algo funcionava em Xray e deixou de funcionar no momento em que mudou, é quase de certeza por isto. Os dois campos de DNS não têm a mesma função nos dois cores.

Campo	Em Xray	Em sing-box
Direct DNS	por predefinição, só resolve destinos em IPs para a correspondência das regras de encaminhamento - não são as suas verdadeiras consultas de saída	faz o trabalho a sério: correspondências de encaminhamento, o domínio do próprio nó e os destinos diretos
Remote DNS	o mesmo, apenas correspondência de encaminhamento	correspondências de encaminhamento e resolução dos destinos passados pelo proxy

Em Xray, estes campos são um pormenor de encaminhamento. Em sing-box, são o seu resolvedor. Copiar para lá uma configuração de DNS que funcionava em Xray é exatamente a forma de acabar com um nó que nem sequer consegue resolver o seu próprio nome de anfitrião.

O Bootstrap DNS tem de ser um endereço IP

A regra está enunciada com clareza na documentação: se o direct DNS ou o remote DNS estiver escrito como domínio, tem de definir um Bootstrap DNS, como endereço IP. É o resolvedor que resolve o seu resolvedor. Introduza https://dns.google/dns-query como remote DNS sem bootstrap e não sobra nada com que procurar dns.google.

A opção relacionada «adicionar hosts de DNS comuns» fixa mapeamentos para dns.google e cloudflare-dns.com, para que uma falha de bootstrap não leve tudo atrás.

Opções que existem apenas num dos cores

Não passe uma noite à procura de uma caixa de seleção que não pode estar lá:

Só em sing-box, e apenas em modo TUN: FakeIP e o bloqueio de consultas SVCB/HTTPS. Este segundo também desliga o ECH e o HTTP/3 - a documentação nota que o ECH pode interferir com o encaminhamento dividido por domínio.
Só em Xray: consultas DNS em paralelo e a cache otimista.

Quanto à estratégia de resolução, UseIPv4 e UseIPv4v6 correspondem ao prefer_ipv4 do sing-box, e UseIPv6/UseIPv6v4 ao prefer_ipv6; ipv4_only e ipv6_only também estão disponíveis. Os hosts de DNS escrevem-se um por linha, no formato domain IP1 IP2. A não ser que tenha uma razão específica, o conselho da própria wiki é importar a configuração de DNS predefinida e não lhe tocar.

Duas alterações de comportamento mais pequenas

O routeOnly é forçado. Com o core sing-box está ativado e não pode ser desligado.
O Mux precisa de um protocolo. Ativar a multiplexagem não chega em sing-box; também tem de escolher o protocolo de multiplexagem - h2mux, smux ou yamux.

Onde ficam os ficheiros

Tudo é relativo à pasta da aplicação:

O quê	Onde
Binários dos cores	`bin\<coreType>` - ou seja, `bin\sing_box`
Configuração gerada para o core	`binConfigs` (`config.json`)
Definições da interface	`guiConfigs` (`guiNConfig.json`)
Registos	`guiLogs`

As compilações em zip são portáteis: tudo fica dentro da pasta onde as extraiu, pelo que pode manter várias cópias independentes lado a lado. Se definir a variável de ambiente V2RAYN_LOCAL_APPLICATION_DATA_V2 com o valor 1, a pasta base passa a ser %LOCALAPPDATA%\v2rayN.

Uma secretária em frente a uma janela luminosa de vários vidros: um monitor grande com um fundo escuro de montanha e céu noturno e um pedido de início de sessão, um portátil aberto por baixo, uma caneca cinzenta salpicada, um frasco pequeno com flores cor-de-rosa e um par de óculos.

Atualize antes de diagnosticar seja o que for

A versão atual à data da redação é o v2rayN 7.24.4, publicado a 30 de julho de 2026, e as suas notas de lançamento assinalam-no como uma atualização de segurança urgente: o descarregador integrado nas versões mais antigas podia ser explorado num ataque man-in-the-middle que servia ficheiros maliciosos. O projeto diz a todos os utilizadores para atualizarem imediatamente. Se estiver numa compilação mais antiga, faça-o antes de começar a depurar um problema de proxy.

Os ficheiros para Windows são distribuídos como seis zips - compilações WPF (v2rayN-windows-64.zip) e Avalonia (v2rayN-windows-64-desktop.zip), em x64, x86 e arm64 - a par de um ficheiro de chave pública para verificar as assinaturas. É necessário Windows 10 ou mais recente.

Do outro lado, a versão estável atual do sing-box é a v1.13.16, publicada a 3 de agosto de 2026. Uma lacuna que vale a pena admitir: nem a wiki nem as notas de lançamento da 7.24.4 publicam uma matriz de compatibilidade entre as versões do v2rayN e do sing-box, e a compilação exata do sing-box incluída no zip não está documentada - seria preciso inspecionar o binário para a conhecer.

Deve mudar?

Só com um motivo. Se os seus nós forem VLESS ou VMess com REALITY, o core Xray é o caminho mais documentado e não há nada a ganhar. Mude quando tiver um nó TUIC, AnyTLS ou Naive para correr, ou quando quiser FakeIP em modo TUN - e, quando o fizer, refaça as definições de DNS de raiz em vez de partir do princípio de que as do Xray se aplicam.

Gerir o seu próprio endpoint em vez de um nó público é uma decisão à parte; se é para aí que se dirige, o nosso guia anti-DPI e de contorno da censura cobre o que sobrevive realmente à inspeção profunda de pacotes.

★ Datacenter GDPR em Nuremberg · ✓ IPv4 dedicado incluído · 200+ Mbps garantidos

Um VPS que controla por completo para tunneling e ofuscação → ContaboAcesso root · abra qualquer porta · execute a sua própria stack→

Perguntas frequentes

Como é que mudo o v2rayN para o core sing-box?

Abra as definições e use «Definições → Tipo de core (Core Type Settings)». O v2rayN resolve o core em dois passos: lê primeiro o tipo de core definido no perfil de servidor atual e, só se esse estiver vazio, recorre ao tipo de core definido globalmente. Assim, um único servidor pode correr em sing-box enquanto o resto da sua lista permanece em Xray. Note que, no código, apenas dois cores geram uma configuração enquanto core principal, o Xray e o sing_box; os restantes cores suportados são conduzidos através de um ficheiro de configuração personalizado.

Que protocolos exigem mesmo o core sing-box no v2rayN?

Três: TUIC, AnyTLS e Naive. Isto não é uma questão de opinião - o próprio v2rayN calcula a lista, como o conjunto dos protocolos suportados pelo sing-box menos os suportados pelo Xray. Todo o resto da lista comum (VMess, VLESS, Shadowsocks, Trojan, WireGuard, SOCKS, HTTP) funciona em qualquer um dos cores.

O Hysteria2 precisa do core sing-box?

Não. O Hysteria2 aparece tanto na lista de protocolos suportados pelo Xray como na do sing-box no v2rayN, pelo que o core Xray também o trata. Esta é uma ideia errada muito comum. À parte disso, alguns utilizadores relataram problemas práticos com o Hysteria2 em Xray no rastreador de issues do projeto, mas um bug reportado não é o mesmo que uma funcionalidade em falta, e não é razão para afirmar que o Xray não consegue fazer Hysteria2.

O XTLS Vision e o REALITY funcionam com o core sing-box?

Sim, ambos. O construtor de outbounds sing-box do v2rayN emite o flow Vision para VLESS e gera o bloco REALITY (chave pública e short ID) do lado do cliente, juntamente com a impressão digital uTLS. Um pormenor que vale a pena saber: a variante «xtls-rprx-vision-udp443» é normalizada para o simples «xtls-rprx-vision».

Porque é que o meu DNS deixou de funcionar depois de mudar para sing-box?

Porque os campos de DNS não significam a mesma coisa nos dois cores. Em Xray, os campos «direct DNS» e «remote DNS» são usados por predefinição apenas para resolver destinos em IPs ao fazer corresponder as regras de encaminhamento - não são as suas verdadeiras consultas de DNS de saída. Em sing-box, esses mesmos campos fazem a resolução real: o direct DNS trata das correspondências de encaminhamento, do domínio do próprio nó e dos destinos diretos, enquanto o remote DNS trata dos destinos passados pelo proxy. Uma configuração que parecia correta em Xray pode, por isso, avariar no momento em que muda.

O que é o Bootstrap DNS e quando é que preciso dele?

É o resolvedor usado para procurar o nome de domínio do seu próprio servidor de DNS. A regra oficial é explícita: se introduzir o direct DNS ou o remote DNS como domínio (por exemplo, um URL DNS-over-HTTPS), tem de definir um Bootstrap DNS, e este tem de ser indicado como endereço IP. Caso contrário, nada consegue resolver o próprio resolvedor. Existe também uma opção para adicionar hosts de DNS comuns, que fixa mapeamentos para dns.google e cloudflare-dns.com, de modo que uma falha de Bootstrap seja sobrevivível.

Que opções de DNS são exclusivas de um dos cores?

O FakeIP e o bloqueio de consultas SVCB/HTTPS funcionam apenas com o core sing-box, e apenas em modo TUN. As consultas DNS em paralelo e a cache otimista funcionam apenas com o core Xray. Bloquear SVCB/HTTPS também desativa o ECH e o HTTP/3; a documentação oficial nota que o ECH pode interferir com o encaminhamento dividido por domínio.

Onde é que o v2rayN guarda o binário sing-box e a configuração que gera?

Relativamente à pasta da aplicação: os binários dos cores ficam em bin\<coreType>, ou seja bin\sing_box para este, e a configuração gerada para o core acaba em binConfigs. As definições da interface estão em guiConfigs (guiNConfig.json) e os registos em guiLogs. As compilações em zip são portáteis - tudo fica na pasta onde extraiu, pelo que podem coexistir várias cópias independentes. Definir a variável de ambiente V2RAYN_LOCAL_APPLICATION_DATA_V2 com o valor 1 move a pasta base para %LOCALAPPDATA%\v2rayN.