Httpcess: Redirecionar um subdomínio para outro protocolo ______ qstntxt ___ Eu gostaria de criar uma regra para um subdomínio, então meu subdomínio de timespeak será redirecionado diretamente para o protocolo ts3. Então, deixe-me mostrar um exemplo: %pre% Infelizmente, isso não está funcionando (resultando em um loop infinito). Para ser honesto, não tenho experiência com o .htaccess. com o que isso deveria parecer? Tentei alguns outros exemplos, mas a maioria deles apenas reescrever em um diretório ou redirecionar para outro domínio, então eu estou com falta de exemplos ... É possível fazer o que estou tentando? ______ azszpr222775 ___ O TL; DR %code% não foi feito para isso, e o TS3 não entenderia o tráfego HTTP do Apache (por vários motivos relacionados ao protocolo). A melhor solução é provavelmente fazer com %code% um alias para %code% (na configuração de DNS do seu domínio) e pedir a seus clientes que se conectem a %code% , onde %code% é sua porta de conexão Teamspeak. %code% arquivos são usados pelo servidor web Apache. Faz parte de um sistema que lida com o tráfego HTTP. O Teamspeak 3 não entende o tráfego HTTP ... porque não é um servidor HTTP. Portanto, redirecionar o tráfego HTTP para o TS3 com um arquivo %code% (supondo que era o caminho certo para fazer isso) não faria muito sentido: o TS3 simplesmente descartaria os pedidos, já que não pode entender as solicitações HTTP. O serviço Teamspeak está associado a uma porta, não a um endereço. Se você usar %code% , na verdade poderá encontrar essa porta. Eu não estou muito familiarizado com o Teamspeak, mas ouvi falar das portas 9987 e 10011 ... Você teria que verificar sua configuração do TS3 para isso:) Se você quiser redirecionar tudo o que vem de %code% para %code% , recomendamos que você configure seu nome de domínio para funcionar dessa maneira. Faça %code% um alias para %code% e todas as solicitações enviadas para %code% chegarão a %code% . Esse tipo de configuração é normalmente tratado pelo seu servidor de nomes autoritativo e você deve ter acesso ao gerenciamento de zonas DNS para aplicar suas alterações. Agora, redirecionar o tráfego all proveniente do %code% para a porta 9987 é mais complicado, e também é muito contraproducente. Teamspeak usa várias portas (consultas, dados de voz, transferências de arquivos ...): se você enviar tudo para 9987, talvez não receba consultas e transferências de arquivos, possivelmente tornando a conexão inicial impossível. Além disso, sua máquina não conseguirá distinguir o tráfego proveniente de %code% do que vem de %code% , já que o cliente o atingiu por IP após a resolução do nome. Um servidor HTTP (ou talvez, proxy) poderia, de fato, fazer essa distinção usando o cabeçalho HTTP %code% , mas há tantos problemas relacionados a protocolos a serem tratados aqui: O HTTP é baseado em conexões, o tráfego teria que ser transportado de TCP para UDP ( hello overhead! ). O cabeçalho %code% teria que ser removido para que somente os dados binários do TS3 permaneçam. Misturar texto e dados binários é, obviamente, uma ideia terrível. O proxy também precisaria ser capaz de distinguir dados de voz de transferências de arquivos e consultas TS3 ... e tenho certeza de que esse proxy não existe. ... ___

Question

Eu gostaria de criar uma regra para um subdomínio, então meu subdomínio de timespeak será redirecionado diretamente para o protocolo ts3.

Então, deixe-me mostrar um exemplo:

RewriteCond %{HTTP_HOST} ^(ts\.)?example\.com$ [NC]
RewriteRule ^(.*)$ ts3://example.com/$1 [R=301,L]

Infelizmente, isso não está funcionando (resultando em um loop infinito).

Para ser honesto, não tenho experiência com o .htaccess. com o que isso deveria parecer? Tentei alguns outros exemplos, mas a maioria deles apenas reescrever em um diretório ou redirecionar para outro domínio, então eu estou com falta de exemplos ...

É possível fazer o que estou tentando?

    

Answer 1

O TL; DR .htaccess não foi feito para isso, e o TS3 não entenderia o tráfego HTTP do Apache (por vários motivos relacionados ao protocolo). A melhor solução é provavelmente fazer com ts.example.com um alias para example.com (na configuração de DNS do seu domínio) e pedir a seus clientes que se conectem a ts.example.com:x , onde x é sua porta de conexão Teamspeak.

.htaccess arquivos são usados pelo servidor web Apache. Faz parte de um sistema que lida com o tráfego HTTP. O Teamspeak 3 não entende o tráfego HTTP ... porque não é um servidor HTTP. Portanto, redirecionar o tráfego HTTP para o TS3 com um arquivo .htaccess (supondo que era o caminho certo para fazer isso) não faria muito sentido: o TS3 simplesmente descartaria os pedidos, já que não pode entender as solicitações HTTP.

O serviço Teamspeak está associado a uma porta, não a um endereço. Se você usar netstat , na verdade poderá encontrar essa porta. Eu não estou muito familiarizado com o Teamspeak, mas ouvi falar das portas 9987 e 10011 ... Você teria que verificar sua configuração do TS3 para isso:)

Se você quiser redirecionar tudo o que vem de ts.example.com para example.com , recomendamos que você configure seu nome de domínio para funcionar dessa maneira. Faça ts.example.com um alias para example.com e todas as solicitações enviadas para ts.example.com:9987 chegarão a example.com:9987 . Esse tipo de configuração é normalmente tratado pelo seu servidor de nomes autoritativo e você deve ter acesso ao gerenciamento de zonas DNS para aplicar suas alterações.

Agora, redirecionar o tráfego all proveniente do ts.example.com para a porta 9987 é mais complicado, e também é muito contraproducente. Teamspeak usa várias portas (consultas, dados de voz, transferências de arquivos ...): se você enviar tudo para 9987, talvez não receba consultas e transferências de arquivos, possivelmente tornando a conexão inicial impossível. Além disso, sua máquina não conseguirá distinguir o tráfego proveniente de ts.example.com do que vem de example.com , já que o cliente o atingiu por IP após a resolução do nome.

Um servidor HTTP (ou talvez, proxy) poderia, de fato, fazer essa distinção usando o cabeçalho HTTP Host , mas há tantos problemas relacionados a protocolos a serem tratados aqui:

• O HTTP é baseado em conexões, o tráfego teria que ser transportado de TCP para UDP ( hello overhead! ).
• O cabeçalho Host: teria que ser removido para que somente os dados binários do TS3 permaneçam. Misturar texto e dados binários é, obviamente, uma ideia terrível.
• O proxy também precisaria ser capaz de distinguir dados de voz de transferências de arquivos e consultas TS3 ... e tenho certeza de que esse proxy não existe.
• ...