常见问题

O SSLcat é um servidor de proxy reverso SSL de código aberto e nível corporativo escrito em Go. Ele reúne nginx + Caddy + Web UI + GitOps em um único binário: emissão e renovação automáticas via Let's Encrypt, roteamento inteligente por domínio, balanceamento de carga, WAF, hospedagem de aplicações Docker / Runner e um painel administrativo Web moderno. A partir da v2.1 também acompanha um servidor MCP integrado para que clientes de IA como Claude / Cursor possam invocar suas ferramentas diretamente.

MCP (Model Context Protocol) é um protocolo aberto que conecta clientes de IA a ferramentas externas. A partir da v2.1, o próprio SSLcat é um servidor MCP e, a partir da v2.3.0-rc1, expõe 22 ferramentas (CRUD de sites / certificados / rotas de proxy, verificação de saúde de upstream, consulta de tarefas de longa duração, e `error_log_list` / `error_log_tail` para inspecionar erros recentes) mais 5 recursos (configuração atual com dados sensíveis ocultados, snapshot de métricas de execução, tail do log de acesso, fontes do log de erro, conteúdo do log de erro). Coloque um token no Claude Desktop / Cursor / Cherry Studio / Continue.dev e a IA poderá listar sites, emitir certificados, alterar rotas e inspecionar logs de acesso / erro — ações destrutivas ainda passam por uma confirmação em duas fases.

Em uma linha no macOS / Linux: `curl -fsSL https://raw.githubusercontent.com/xurenlu/sslcat/main/install.sh | bash`. Você também pode baixar binários na página de Releases do GitHub (linux-amd64 / linux-arm64 / darwin-arm64 / darwin-amd64). A documentação completa está em `docs/` e no site.

Sim. O SSLcat integra Let's Encrypt (ACME). Adicionar um domínio aciona a emissão automática, e os certificados são renovados 30 dias antes do vencimento sem tempo de inatividade. Tanto os desafios HTTP-01 quanto DNS-01 são suportados; DNS-01 combinado com AWS Route53 (e outros provedores) permite emitir certificados curinga como `*.example.com`.

Em comparação ao nginx: o SSLcat vem com painel Web, SSL automático, implantação GitOps, monitoramento em tempo real e segurança orientada por IA prontos para uso — sem mais edição manual de arquivos de configuração. Em comparação ao Caddy: o SSLcat oferece 6 algoritmos de balanceamento de carga, gerenciamento multiusuário, implantação por imagem Docker e Runner, um sistema de tokens de API, streaming de logs ao vivo baseado em WebSocket e, a partir da v2.1, a integração MCP integrada.

Suporte completo a HTTP/1.1, HTTP/2 e HTTP/3 (QUIC), com TLS 1.3 imposto. Conexões WebSocket e SSE de longa duração recebem tratamento especial, e tarefas longas do ACME usam heartbeats, isenções de tempo limite de escrita e isolamento de concorrência por domínio para que não possam arrastar umas às outras para baixo.

Seis algoritmos são integrados (round-robin, round-robin ponderado, least-conn, IP hash, aleatório, resposta mais rápida), combinados com verificações de saúde TCP e afinidade de sessão. Você pode anexar uma lista de backends com pesos no nível da rota em um único domínio.

Adicione o SSLcat como um remoto Git e então execute `git push sslcat main` para implantar — estilo Dokku/Heroku. O ponto de entrada de implantação do Runner é em camadas: faça upload de um diretório, envie um binário, baixe diretamente uma imagem Docker, faça build a partir de `git push` ou use um template. Todos os caminhos convergem para a mesma especificação unificada do Runner (variáveis de ambiente, portas, montagens, comando de inicialização).

O Runner é a camada de hospedagem de aplicações integrada ao SSLcat. Ele pode executar contêineres Docker, executar binários enviados, executar imagens construídas a partir de `git push` ou implantar a partir de templates. Quando o próprio SSLcat é reiniciado, ele apenas reconcilia o estado dos contêineres do Runner — nunca reinicia seus contêineres de negócio, então o tráfego de produção nunca é interrompido acidentalmente.

Correspondência de regras WAF (a varredura do corpo da requisição é limitada a 1 MB para manter a memória controlada), proteção contra DDoS, anti-força-bruta, lista de bloqueio e permissão por IP / UA / impressão digital TLS, tokens de API granulares, MFA por TOTP, logs de auditoria, gerenciamento de versões de configuração e um detector de anomalias por IA baseado em Isolation Forest com treinamento online, persistência do modelo em JSON e inferência sobre tráfego real.

Prefira o comando de redefinição integrado: `sslcat users password -username admin -new-password 'NewStrongPass123!'`. A partir de uma árvore de código-fonte você também pode executar: `go run tools/cmd/reset_password/main.go admin 'NewStrongPass123!'`. A partir da v2.0.0-rc22 você também pode redefinir via código de recuperação de uso único. Para gerar um hash bcrypt manualmente com Ruby: instale o bcrypt com `gem install bcrypt`, depois execute `SSL_PASS='NewStrongPass123!' ruby -rbcrypt -e 'puts BCrypt::Password.create(ENV.fetch("SSL_PASS"), cost: 10)'`. Com Python: `python3 -m pip install bcrypt`, depois `SSL_PASS='NewStrongPass123!' python3 -c 'import bcrypt, os; print(bcrypt.hashpw(os.environ["SSL_PASS"].encode(), bcrypt.gensalt(rounds=10)).decode())'`. Escreva o hash em `admin.password_file` (comumente `/opt/sslcat/data/admin.pass` ou `./data/admin.pass`) com modo `600`. A recuperação por arquivo de senha geralmente não requer reiniciar o SSLcat — o próximo login lê o novo hash.

`http://<your-host>:8080/sslcat-panel/`, conta padrão `admin`, senha padrão `admin*9527` (altere-a no primeiro login). O prefixo da URL administrativa e a porta de gerenciamento são ambos configuráveis.

Sim. O SSLcat emite certificados curinga como `*.example.com` via o desafio DNS-01 do Let's Encrypt. Domínios curinga são forçados para DNS-01 automaticamente e se integram ao AWS Route53 e a outros provedores de DNS para verificação.

Adicione um domínio, host de destino e porta em "Sites" no painel administrativo. Para adicionar múltiplos backends, habilite `load_balancer_enabled`, escolha o algoritmo (round_robin / least_conn / ip_hash etc.), ative as verificações de saúde e liste os backends. Você também pode editar diretamente a configuração JSON (o SSLcat usa JSON, não YAML).

Sim. A linha v2.0 continua reforçando os caminhos de produção: gravações atômicas para certificados, chaves, versões de configuração, tokens e sessões; Stop / Close idempotentes em cada componente; cache de upstream mais seguro sob concorrência; WAF de alto rendimento; conexões longas HTTP/2 / HTTP/3 / WebSocket sólidas como rocha. Ajustes recentes reduziram a CPU em estado ocioso de 50–100% para <1% e configurações multi-Runner em cerca de 97%.

1) Habilite o MCP: `sslcat mcp enable`. 2) Crie um token: `sslcat mcp token create --name claude-desktop --scopes read,site:write,cert:write`. O token em texto puro é exibido apenas uma vez — armazene-o com segurança. 3) Configure o Claude Desktop com o endpoint Streamable HTTP (padrão `https://your-domain/sslcat-panel/mcp/stream`) e o token bearer. Veja `docs/mcp-client-setup.md` para configurações completas cobrindo Cursor, Cherry Studio, Continue.dev e depuração via curl.

Sim. Toda ferramenta destrutiva usa confirmação em duas fases: a primeira chamada retorna uma prévia de dry-run com informações de impacto (por exemplo, `cert_delete` sinaliza se o certificado é referenciado por uma regra de proxy e quantos dias restam; `proxy_route_delete` lista prefixos e backends) mais um `confirm_token` com TTL de 60 segundos. A IA deve passar esse token de volta no argumento `confirm` de uma segunda chamada para realmente executar. Os tokens são vinculados a (token_name, tool, hash dos args), então não podem ser reutilizados entre ferramentas ou argumentos.

Um Isolation Forest é integrado ao SSLcat. Um `RequestSampler` extrai características de cada requisição real em um buffer circular de 5.000 posições; o treinamento puxa amostras diretamente do anel e persiste a floresta como JSON em `${data_dir}/ml/isolation_forest.json` (carregado automaticamente na próxima inicialização). As inferências caem em um buffer circular de 200 posições, então a aba "Detecções recentes" do painel administrativo reflete tráfego real, não dados mock codificados.

Linux (todas as principais distribuições), macOS e Windows; binários amd64 e arm64 são publicados. Recomendamos executar o SSLcat sob systemd no Linux para produção.

Mínimo: 512 MB de RAM, 100 MB de disco. Recomendado: 2 GB de RAM, 1 GB de disco. Compilar a partir do código-fonte requer Go 1.21+.

Todos eles. O WebSocket é encaminhado de forma transparente para o upstream; o SSE em HTTP/2 / HTTP/3 é ajustado para que os tempos limite de escrita não possam matar fluxos de longa duração; sites PHP funcionam por meio de um backend FastCGI.

O painel administrativo lê logs com tailing limitado (arquivos de log grandes nunca são puxados para a memória). Você também pode aplicar tail diretamente no arquivo de log configurado. Via MCP, clientes de IA podem obter o tail com um recurso como `sslcat://logs/access?since=10m&domain=foo.com&limit=200`.

O SSLcat tem como alvo o Let's Encrypt prontamente — uma CA pública gratuita que existe para tornar o HTTPS o padrão. Você ainda pode fazer upload de certificados comerciais via `cert_upload`; o SSLcat valida o parsing PEM, o pareamento certificado/chave e a cobertura de CN/SAN.

1) `sslcat doctor --json` executa uma autoverificação imediata em config, portas, diretório de certificados, raízes de site, upstreams e estado dos tokens MCP. 2) `sslcat status --json` exibe versão, parâmetros de escuta e resumo de site / certificado / MCP. 3) Leia o log de erro do SSLcat e `${data_dir}/mcp_audit.YYYYMMDD.log`, ou deixe a IA lê-los via as ferramentas MCP `error_log_list` / `error_log_tail` (cobre o próprio SSLcat mais cada site proxy / estático / php). 4) `sslcat proxy health-check --domain foo.com --include-routes --json` sonda o backend principal e cada backend de PathPrefixRule em paralelo. 5) O servidor expõe sua versão via os headers de resposta `X-App-Version` / `X-Server-Version` para que você possa confirmar qual imagem está realmente servindo o tráfego.

A v2.2.0-rc1 adiciona comandos de operações via CLI: `sslcat status [--json]` (resumo de execução), `sslcat doctor [--json]` (autoverificação em config / portas / certs / raízes de site / upstreams / tokens MCP), `sslcat site list/add/update/delete/enable/disable` (CRUD para sites estáticos e PHP — a exclusão requer `--yes` explícito) e `sslcat proxy health-check [--domain] [--include-routes] [--json]` (sondagem TCP). O global `-config` pode ser colocado antes do subcomando. A v2.3.0-rc1 adiciona as ferramentas MCP `error_log_list` e `error_log_tail`, além dos recursos `sslcat://logs/error-sources` e `sslcat://logs/error{?id,kind,domain,since,keyword,limit,max_bytes}` para que clientes de IA possam listar e ler erros recentes do próprio SSLcat e de sites individuais. Sob o capô, `internal/mcp/logview` é um leitor de log limitado (padrão para o último 1 MB, máximo 4 MB) para que arquivos de log grandes não possam bloquear o caminho da requisição.

Já entregue: integração MCP completa P1–P5 (v2.1.0), comandos de operações via CLI e autoverificação (v2.2.0-rc1), leitura de log de erro do MCP mais o leitor de log limitado (v2.3.0-rc1). Planejado: integração com Kubernetes, suporte multi-cluster, estratégias avançadas de cache, um sistema de plugins e uma API GraphQL.

MIT. Código, issues e releases vivem todos no GitHub: https://github.com/xurenlu/sslcat . Issues, PRs e casos de uso adicionais em `docs/` são muito bem-vindos.