Como configurar

NTProxy: 1 porta, todos os protocolos

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:

• SSL/TLS (security) ative TLS no app + SNI (bug)
• Payload (HTTP) cole um payload (modelos abaixo)
• SSH puro SSL/TLS sem payload (estilo stunnel)

WebSocket real também: se o app manda um handshake WS de verdade (com Sec-WebSocket-Key), o NTProxy responde o 101 Switching Protocols com o Sec-WebSocket-Accept correto.

SSH + Xray na mesma porta: o motor Xray roda embutido no próprio NTProxy (sem porta/certificado separados) — ele reconhece o tráfego Xray por SNI/ALPN e path (XHTTP), roteando direto pro protocolo configurado. 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.

1) Proxy + Payload (HTTP)

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.

• Servidor / Porta BUG:22
• Proxy / Porta SEU_IP:PORTA_NT
• Payload GET ... [crlf][crlf]
• Usuário / Senha os do SSH

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].

2) Proxy + Payload (TLS/SSL)

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.

• Servidor / Porta BUG:22
• Proxy / Porta SEU_IP:PORTA_NT_TLS
• SNI seu bug
• TLS 1.2 ou 1.3

Modelos de payload

Teste qual passa na sua operadora e use no card 1 ou 2. O [host] é o seu bug — não precisa trocar.

Por operadora (apelido pela cor)

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.

3) SSL/TLS direto (sem payload)

Túnel TLS puro até a porta (modo "SSL"). Não usa payload — só o SNI.

• Servidor:Porta SEU_IP:PORTA_TLS
• SNI (bug) seu bug
• Usuário / Senha os do SSH

4) SSH_XHTTP (HTTP/2)

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.

• Servidor / Porta HOST_FRONT:PORTA_NT
• Proxy / Porta SEU_IP:PORTA_NT
• SNI seu domínio TLS (ou vazio sem TLS)
• TLS TLSv1.2 ou TLSv1.3
• Usuário / Senha os do SSH

5) SlowDNS

Túnel por DNS — funciona até em redes bem fechadas. Pegue o NS e a chave pública no menu do SlowDNS.

• NS (name server) do menu
• Chave pública do menu (server.pub)
• DNS 1.1.1.1
• Usuário / Senha os do SSH

6) Xray nativo (VLESS / VMess)

No menu do Xray, copie o link do modo instalado e importe no app por link/URI. O motor roda embutido no próprio NTProxy — sem porta nem certificado separados. O SSH_XHTTP usa h2, então pode usar o mesmo bug na porta compartilhada; o NTProxy separa pelo ALPN/path antes de aplicar o encaminhamento. Nos modos CDN, o domínio de conexão/SNI e o Host do CDN precisam apontar para a mesma configuração da Cloudflare.