Escolher entre terminação TLS e passagem TLS não é uma configuração de proxy cosmética. Decide onde a encriptação termina, qual sistema detém as chaves de sessão, se Webship pode inspecionar o HTTP, e qual camada deve aplicar a segurança da aplicação.
Webship tem como padrão o modo de passagem. Isso mantém o texto simples da aplicação e as chaves de sessão ativas na origem. Ative a terminação apenas quando a borda precisar compreender e agir sobre o pedido HTTP.
A decisão em uma frase
Use encaminhamento TLS quando a origem deve possuir a fronteira TLS. Use terminação TLS quando Webship precisar encaminhar, proteger, transformar, armazenar em cache ou observar o tráfego HTTP.
Nenhum modo é universalmente mais seguro. O modo de passagem reduz o material sensível processado na borda, mas remove os controlos de segurança HTTP da borda. A terminação adiciona um ponto de aplicação inspecionável, mas torna Webship parte da fronteira TLS confiável.
| Preocupação | Terminação TLS | Passagem TLS | | --- | --- | --- | | Ponto final TLS | Webship | Origem | | Texto simples da aplicação em Webship | Sim | Não | | Chaves de sessão ativas a jusante em Webship | Sim | Não | | Rota por caminho ou método HTTP | Sim | Não | | WAF, Escudo API e limites de corpo em Webship | Sim | Não | | Cache de proxy, reescritas e encaminhamento de cabeçalhos | Sim | Não | | Entrada de encaminhamento TCP | Autoridade HTTP e política de rota | ClientHello SNI | | HTTP/3 encaminhamento | Dados de pedido HTTP | Uma origem UDP partilhada | | Responsabilidade de origem | TLS HTTP ou TLS upstream configurado separadamente | TLS completo, ALPN e pilha HTTP |
A questão importante não é, portanto, «Qual interruptor é mais rápido?» É «Qual componente deve ser autorizado a ver e controlar o pedido?»
Que rescisão dá Webship
Com tls_termination = true, Webship conclui o TLS a montante e encaminha a requisição descriptografada para a sua pipeline de proxy reverso HTTP. Isso torna possíveis as seguintes funcionalidades:
- encaminhamento consciente de caminho, host e método;
- Inspeção WAF e API Shield;
- limites do corpo da requisição e tempos limite da política;
- cache de proxy e invalidação segura para geração;
- gestão de cabeçalhos de encaminhamento e campos de registo de acesso HTTP;
- manuseamento de CONSULTA consciente do corpo, tentativas novamente quando seguro, e política de disjuntor;
- tradução de protocolo entre as ligações voltadas para o cliente e as ligações ascendentes.
Este modo também altera a responsabilidade de segurança. O anfitrião Webship deve proteger a chave privada do certificado, as chaves de sessão, os dados de pedidos e respostas descodificados, a saída de observabilidade e qualquer representação em cache. Se o próximo salto precisar permanecer encriptado, configure separadamente o TLS a montante tipado; caso contrário, o HTTP a montante é em texto simples.
A terminação é o limite correto quando Webship é esperado comportar-se como uma borda ciente da aplicação, e não apenas como um relé de transporte encriptado.
O que a passagem preserva
Com tls_termination = false—o padrão—Webship retransmite tráfego encriptado TLS ou QUIC sem descodificar o pedido ou resposta HTTP. O texto em claro da aplicação e as chaves de sessão ativas mantêm-se na origem.
Essa fronteira de confiança mais pequena é valiosa quando os certificados devem permanecer na camada de aplicação, a política de conformidade proíbe a descodificação na borda ou uma identidade TLS específica da origem deve alcançar o cliente sem alterações. Também elimina a análise HTTP e o trabalho de políticas do caminho de retransmissão.
O compromisso é rigoroso: Webship não consegue inspecionar o que não pode descodificar. Não pode aplicar regras WAF HTTP, encaminhar por caminho, reescrever cabeçalhos, impor políticas de API conscientes do corpo, ou preencher registos de acesso a campos HTTP. A origem deve fornecer todos esses controlos por si própria.
O pass-through, portanto, não é uma "resolução com menos funcionalidades." É uma arquitetura diferente com um proprietário de segurança diferente.
Os limites específicos do protocolo são importantes
Para HTTP/1.1 TLS e HTTP/2 TLS, Webship inspeciona o ClientHello apenas o suficiente para selecionar o destino TCP configurado pelo SNI. Cada domínio de passagem precisa de uma rota path_prefix = "/" genérica porque o caminho real do pedido permanece encriptado. Um cliente sem SNI é aceite apenas quando a configuração tem um único domínio.
A origem deve negociar o ALPN do cliente e suportar o protocolo selecionado. Webship não pode converter um cliente HTTP/2 em uma origem HTTP/1.1 enquanto a sessão TLS passa inalterada.
HTTP/3 usa QUIC sobre UDP e tem uma fronteira mais restrita. O encaminhamento direto não pode rotear com segurança pela autoridade HTTP encriptada, portanto cada rota configurada HTTP/3 deve resolver para o mesmo socket-IP de origem UDP. Webship rejeita sockets Unix e múltiplas origens de encaminhamento direto HTTP/3 durante a validação da configuração em vez de encaminhar silenciosamente de forma ambígua.
O texto simples HTTP/1.1 e h2c não são afetados por reverse_proxy.tls_termination. A configuração controla apenas o TLS descendente HTTP/1.1, TLS HTTP/2 e TLS HTTP/3.
Capacidade de solicitação medida
O Webship 1.3.1 Benchmark de capacidade Debian mediu separadamente os dois modos de proxy inverso encriptados. Cada amostra aceite exigiu zero erros de HTTP, socket, protocolo, proxy, falha de página principal e perda de pacotes HTTP/3.
| Modo reverse-proxy | HTTP/1.1 TLS | HTTP/2 TLS | HTTP/3 TLS | | --- | ---: | ---: | ---: | | Terminação TLS | 123.344 RPS | 124.957 RPS | 131.529 RPS | | Passagem TLS | 203.950 RPS | 266.845 RPS | 167.010 RPS |
O encaminhamento de resposta pequena tem menos trabalho de aplicação a realizar: retransmite dados de transporte encriptados em vez de terminar o TLS, analisar o HTTP, avaliar a política e produzir um novo fluxo TLS descendente. As taxas mais altas de pedidos em encaminhamento refletem essa função mais limitada.
Estas linhas não representam conjuntos de funcionalidades idênticas e não devem ser usadas para afirmar que uma arquitetura de segurança é universalmente melhor. A terminação paga por capacidades conscientes de HTTP que o encaminhamento intencionalmente não pode fornecer.
A transmissão em massa altera o resultado
O mesmo benchmark utilizou um corpo de resposta de exatamente 99.943.778 bytes para a matriz de streaming de 100 MB. Aqui, a terminação TLS produziu uma maior taxa média de transferência de carga útil para os três protocolos:
| Modo reverse-proxy | HTTP/1.1 TLS | HTTP/2 TLS | HTTP/3 TLS | | --- | ---: | ---: | ---: | | Terminação TLS | 3.585,7 MiB/s | 3.355,0 MiB/s | 1.938,6 MiB/s | | Passagem TLS | 2.783,2 MiB/s | 2.135,0 MiB/s | 1.748,5 MiB/s |
Por que é que a direção muda? No modo de terminação, a origem do benchmark envia HTTP em texto claro para Webship, e Webship gere o caminho de bulk otimizado a jusante. Grandes respostas HTTP/1.1 e HTTP/2 podem usar kTLS adaptativo no Linux e bufferização limitada específica de transporte. HTTP/3 utiliza pacing QUIC, DPLPMTUD e batching por reactor em vez de kTLS.
No modo pass-through, a origem detém o TLS a jusante e o Webship retransmite o fluxo criptografado resultante ou os pacotes QUIC. Isso preserva a fronteira TLS da origem, mas não permite utilizar o caminho de resposta em massa com conhecimento de HTTP do Webship.
A qualificação de sete amostras HTTP/3 também verificou a estabilidade. A transmissão interrompida atingiu uma mediana de 1.938,6 MiB/s com 2,12% de coeficiente de variação; o pass-through atingiu 1.748,5 MiB/s com 1,65% de coeficiente de variação. Ambos entregaram o corpo exato sem erros de cliente, protocolo ou perda de pacotes.
Configure a passagem direta deliberadamente
Uma configuração mínima de passagem mantém a identidade TLS em preparação para que um operador possa ativar a terminação mais tarde sem alterar os caminhos dos certificados:
[reverse_proxy]
enabled = true
tls_termination = false
[reverse_proxy.protocols]
h1 = true
h2 = true
h3 = true
[reverse_proxy.tls]
cert = "/etc/webship/proxy-cert.pem"
key = "/etc/webship/proxy-key.pem"
[[reverse_proxy.routes]]
domain = "app.example.com"
path_prefix = "/"
upstreams = ["10.0.0.20:443"]
[[reverse_proxy.policies]]
name = "default"
path_prefixes = ["/"]
total_timeout_ms = 30000O certificado em fase de teste Webship é validado, mas não é utilizado por sessões ativas de passagem. A origem em 10.0.0.20:443 deve terminar o TLS e suportar o protocolo negociado pelo cliente.
Ativar terminação quando a borda precisar de HTTP
Para uma edge consciente da aplicação, ative a terminação e envie o tráfego HTTP resultante para a origem selecionada:
[reverse_proxy]
enabled = true
tls_termination = true
[reverse_proxy.protocols]
h1 = true
h2 = true
h3 = true
[reverse_proxy.tls]
cert = "/etc/webship/proxy-cert.pem"
key = "/etc/webship/proxy-key.pem"
[[reverse_proxy.routes]]
domain = "app.example.com"
path_prefix = "/api"
strip_path_prefix = true
upstreams = ["10.0.0.20:8080", "10.0.0.21:8080"]
[[reverse_proxy.policies]]
name = "default"
hosts = ["app.example.com"]
path_prefixes = ["/"]
max_body_bytes = 1048576
request_body_idle_timeout_ms = 5000
upstream_header_timeout_ms = 5000
response_body_idle_timeout_ms = 5000
downstream_write_idle_timeout_ms = 5000
total_timeout_ms = 30000Esta configuração pode encaminhar e inspecionar HTTP. Adicione TLS ascendente quando a rede entre Webship e a origem não estiver já confiável ou isolada.
Mude de modo sem reiniciar Webship
Webship pode alterar tls_termination através de um recarregamento do ficheiro de configuração ou da ferramenta webship.reverse_proxy.apply_config MCP com verificação de versão. Leia o objeto e a versão atuais com webship.reverse_proxy.get_config, altere apenas o campo pretendido no objeto completo retornado e submeta-o com o expected_version_id correspondente.
As novas conexões TCP usam o novo modo. Os clientes HTTP/3 reconectam-se ao transporte UDP substituído. As alterações de caminho de certificado e chave permanecem vinculadas ao processo e requerem uma reinicialização, por isso mantenha uma identidade de terminação válida preparada antes de uma alteração em vivo.
A verificação de versão impede que um operador sobrescreva uma alteração de configuração concorrente. Uma atualização rejeitada mantém a configuração ativa em tempo de execução e a configuração persistida inalteradas.
Uma lista de verificação de selecção prática
Escolha passagem direta quando todas estas condições forem verdadeiras:
- A origem deve manter o limite do certificado e as chaves de sessão.
- O encaminhamento TCP ao nível SNI—ou uma origem UDP HTTP/3 partilhada—é suficiente.
- A origem fornece o WAF necessário, autorização, registo, limites de corpo e controlos de abuso.
- Não é necessário cache de borda, reescrita de caminho, política de cabeçalho de encaminhamento ou tradução de protocolo HTTP.
Escolha a terminação quando qualquer um destes for necessário em Webship:
- Rota por host, caminho ou método.
- Inspecionar pedidos com WAF ou API Shield.
- Aplicar limites de corpo, tempos de espera HTTP ou autenticação na borda.
- Armazenar em cache respostas ou reescrever cabeçalhos HTTP.
- Traduzir entre protocolos HTTP descendentes e ascendentes.
- Observe os campos HTTP na fronteira do proxy.
Independentemente do modo que selecionar, teste SNI, ALPN, identidade do certificado, cancelamento pelo cliente, fecho parcial a montante e a integridade exata da resposta. Meça a capacidade de solicitação e a transferência de streaming separadamente: o modo mais rápido para uma resposta pequena não é necessariamente o modo mais rápido para um corpo de 100 MB.
Webship torna o pass-through o padrão porque um proxy não deve alargar silenciosamente o seu limite de confiança. A terminação mantém-se como uma escolha operacional ativa e explícita quando o comportamento de edge consciente de HTTP justifica essa responsabilidade.
Leia a [documentação do reverse-proxy](/docs/1.3.1) completa, compare a [matriz de referência](/benchmarks) aceite ou descarregue Webship a partir de [Downloads](/downloads).
Fontes e método de conteúdo
Os valores de desempenho são medianas aceites do benchmark unificado de capacidade Debian 1.3.1 Webship datado de 11 de setembro de 2026; os seus critérios de aceitação requerem zero erros de cliente, HTTP, socket, protocolo, proxy, falha de página principal e perda de pacotes HTTP/3.