Explicação por modo de conexão. O payload tem botão de copiar; os demais campos você troca pelos seus dados.
A porta do NTProxy detecta o protocolo sozinha (pelo 1º byte, ALPN, SNI, cabeçalhos e caminho). O destino SSH ou Xray só é escolhido quando houver uma assinatura válida; o tipo genérico xhttp sozinho não seleciona o Xray:
Importante: Upgrade: websocket nos exemplos abaixo é apenas um marcador de payload para redes que exigem esse header. O NTProxy aceita o upgrade do payload e responde 101, mas não implementa framing WebSocket nem Sec-WebSocket-Accept; para Xray use XHTTP ou TCP nativo.
SSH + Xray na mesma porta: o motor Xray roda embutido no próprio NTProxy (sem porta/certificado separados). No XHTTP, ele separa pelo SNI/ALPN/path; no XRAY-BHTTP, o NTProxy reconhece o BHTTP binário e encaminha o stream ao VLESS interno. O SSH continua sendo o destino padrão dos fluxos que não pertencem ao Xray.
Compatibilidade: SSH_XHTTP pode usar o mesmo bug/Host da opção 1 porque usa HTTP/2 (h2) e o Xray usa http/1.1. SSH SSL/TLS ou payload que também usem o mesmo SNI e anunciem o mesmo ALPN http/1.1 ainda ficam indistinguíveis nessa camada; sem esse ALPN ou usando h2, continuam no SSH.
Para redes que liberam por payload/bug. O NTProxy aguarda o payload completo e responde uma única vez com HTTP 200 antes do SSH. Preencha Servidor com o bug usado em [host] e Proxy com o endereço real da porta NTProxy.
GET / HTTP/1.1[crlf]Host: [host][crlf]Upgrade: websocket[crlf][crlf]O TurnCore atual resolve: [host], [port], [host_port]/[ssh], [ua], [crlf], [cr], [lf], [lfcr], [cdn], [cdn_rotate], [cdn_random], [cdn_id=...], [cdn_name=...], [rotate=a;b], [random=ip;ip], [instant_split], [split] e [delay_split].
Igual ao HTTP, mas por dentro de TLS. Abra o NTProxy com certificado, preencha Servidor com o bug, Proxy com o endereço real da porta NTProxy e informe o mesmo SNI no app.
GET / HTTP/1.1[crlf]Host: [host][crlf]Upgrade: websocket[crlf][crlf]Teste qual passa na sua operadora e use no card 1 ou 2. O [host] é o seu bug — não precisa trocar.
GET / HTTP/1.1[crlf]Host: [host][crlf]Connection: Keep-Alive[crlf][crlf]CONNECT [host_port] HTTP/1.1[crlf]Host: [host_port][crlf]Proxy-Connection: Keep-Alive[crlf][crlf]GET /[cdn_rotate] HTTP/1.1[crlf]Host: [cdn_name=principal][crlf]User-Agent: [ua][crlf][crlf]GET / HTTP/1.1[crlf]Host: [host][crlf]X-Online-Host: [host][lf]X-Forward-Host: [host][lfcr][crlf]GET / HTTP/1.1[crlf]Host: [host][crlf]Upgrade: websocket[crlf][crlf]GET / HTTP/1.1[crlf]Host: [host][crlf][crlf][split]GET / HTTP/1.1[crlf]Host: [host][crlf]Upgrade: websocket[crlf][crlf]ACL / HTTP/1.1[crlf]Host: [host][crlf]Connection: Upgrade[crlf]Upgrade: websocket[crlf][crlf]GET / HTTP/1.1[crlf]Host: [host][crlf]User-Agent: Mozilla/5.0[crlf]Upgrade: websocket[crlf][crlf]CONNECT [host]:80 HTTP/1.1[crlf]Host: [host][crlf][crlf][instant_split]GET / HTTP/1.1[crlf]Host: [host][crlf]Upgrade: websocket[crlf][crlf]GET / HTTP/1.1[crlf]Host: [host][crlf]X-Online-Host: [host][crlf]X-Forward-Host: [host][crlf]Upgrade: websocket[crlf][crlf]GET ws://[host]/ HTTP/1.1[crlf]Host: [host][crlf]Connection: Upgrade[crlf]Upgrade: websocket[crlf][crlf]PUT / HTTP/1.1[crlf]Host: [host][crlf]Upgrade: websocket[crlf][crlf]GET / HTTP/1.1[crlf]Host: [host][crlf]Connection: keep-alive[crlf]Upgrade: websocket[crlf][crlf]GET / HTTP/1.1[crlf]Host: [host][crlf]Upgrade: websocket[crlf][crlf][split]GET / HTTP/1.1[crlf]Host: [host][crlf]Upgrade: websocket[crlf][crlf][rotate=GET;POST;PUT] / HTTP/1.1[crlf]Host: [host][crlf]Upgrade: websocket[crlf][crlf]Payloads pro modo Proxy + Payload do NTProxy que costumam passar em cada operadora. O [host] = bug; ele muda por operadora/região e é atualizado sempre — use um atual. A estrutura é o ponto de partida.
GET / HTTP/1.1[crlf]Host: [host][crlf]X-Online-Host: [host][crlf]Upgrade: websocket[crlf][crlf]GET / HTTP/1.1[crlf]Host: [host][crlf][crlf][split]GET / HTTP/1.1[crlf]Host: [host][crlf]Upgrade: websocket[crlf][crlf]CONNECT [host]:80 HTTP/1.1[crlf]Host: [host][crlf]Connection: Keep-Alive[crlf][crlf]Túnel TLS puro até a porta (modo "SSL"). Não usa payload — só o SNI.
Não usa payload. O app abre HTTP/2 real, com cinco streams de download e uploads sequenciados. Use Servidor como Host/front, Proxy como endereço real do NTProxy e deixe o payload vazio. Em porta compartilhada, não use o SNI reservado ao Xray.
Importante: o caminho /ssh (SSH por dentro do HTTP, para atravessar CDN) só responde nas portas que têm um inbound XHTTP configurado no menu do Xray — inclusive o protocolo ssh puro, sem VLESS/VMess (ver card 6). Sem nenhum inbound XHTTP na porta, use SSH puro/SSL ou payload, que não passam por HTTP.
Túnel por DNS — funciona até em redes bem fechadas. No menu do SSH Core, ative o SlowDNS e informe o domínio NS e a porta SSH (o menu gera a chave pública). No app, configure o modo SSH_DNSTT com os mesmos dados:
Importante: o campo Resolvedor DNS não é a porta SSH nem precisa ser o IP da VPS. O domínio NS deve apontar para a VPS; o app envia as consultas pelo DNS da rede, UDP, DoH ou DoT.
No terminal, abra Conexões → Xray → Configurar porta e depois escolha o modo:
No modo CDN (automático) o menu pergunta só o que muda de CDN para CDN — o resto já vem pronto:
O link sai pronto assim (copie em Link de usuário e importe no app por link/URI):
vless://UUID_DO_CLIENTE@ENDERECO_DO_LINK:443?encryption=none&security=tls&sni=app.tim.com.br&type=xhttp&host=HOST_DA_CDN&path=%2Fxhttp&allowInsecure=1#nome
vmess://BASE64_DO_JSON_DO_LINK
Porta: o motor roda embutido no NTProxy (sem binário nem certificado separados). Você escolhe usar uma porta NTProxy já aberta (compartilhada) ou pedir uma dedicada, que o menu abre na hora. Dá para ter várias portas com Xray ao mesmo tempo (uma por CDN, por exemplo) — o mesmo usuário/UUID vale em todas, e Link de usuário mostra um link para cada porta.
SSH puro por dentro do XHTTP: no modo Personalizado existe o protocolo ssh — um inbound XHTTP sem cliente VLESS/VMess, que entrega direto no SSH. Não gera link de app: o cliente conecta com usuário/senha SSH normais. É o que destrava o caminho /ssh descrito no card 4.
O SSH_XHTTP usa h2, então pode usar o mesmo bug na porta compartilhada; o NTProxy separa pelo ALPN/path antes de encaminhar. Nos modos CDN, o Host do CDN e o SNI precisam bater com a configuração feita no painel da CDN.
O SSH_BHTTP usa transporte binário sobre TCP, sem payload HTTP, proxy, SNI ou path. Informe a entrada pública do NTProxy e, se quiser autenticação automática, os dados da conta SSH.
Importante: dt_protocol é fixo em TCP; não existe mais seletor de KCP ou UDP neste modo. O bloco bhttp_config guarda o modo, sondagem, chunks, conexões, tentativas e timeouts.
Portas UDP, quando exibidas no perfil, servem apenas ao encaminhamento UDP opcional do SSH e não mudam o transporte BHTTP. Para abrir o BHTTP, libere somente a porta pública em TCP.
É um modo separado do SSH_BHTTP: usa o mesmo transporte binário TCP, mas autentica com UUID e entrega o fluxo ao VLESS nativo do NTProxy. Não usa usuário/senha SSH, payload, proxy, SNI, path, KCP ou UDP.
No SSH Core: abra Conexões → Xray → Configurar porta → XRAY-BHTTP. O menu configura uma porta pública e reinicia a unit responsável: ntproxy-<porta> compartilhada ou sshcore-xraybhttp-<porta> standalone.
Porta interna: uma porta como 127.0.0.1:31285 é somente loopback e pode variar quando há vários BHTTP standalone. Não coloque essa porta no app, não abra no firewall e não procure um serviço Xray separado: o motor VLESS roda dentro do próprio serviço.
No painel: em Configurações → Adicionar, escolha XRay BHTTP e preencha apenas servidor, porta, UUID e o bloco de ajuste BHTTP. O link/cliente usa VLESS + TCP + BHTTP, não um JSON Xray separado.