TenthMatrix WSL Proxy
API Gateway, CDN e WAF empresarial — Visão geral do produto
O TenthMatrix WSL Proxy (WSLProxy) é o plano de controle completo de API gateway e borda CDN da TenthMatrix. Ele fica na frente das suas origens e decide a cada requisição o que acontece — rotear, proteger, cachear e observar — a partir de configurações JSON e MCP ao vivo, sem recarregar o nginx a cada mudança de regra.
O que é o TenthMatrix WSL Proxy?
O WSLProxy é um API gateway dinâmico e proxy reverso sobre OpenResty. Os operadores gerenciam hosts virtuais, regras de roteamento, políticas de WAF, cache, divisão de tráfego e POPs de borda por uma interface de administração, API REST, ferramentas MCP ou o wslproxy-cli. As regras do dia a dia entram em vigor no caminho crítico; o nginx só recarrega quando blocos listen ou SSL no nível do servidor mudam.
Watch the overview
Assista: introdução ao TenthMatrix WSL Proxy
Assistir
Assistir no YouTube: Assista: introdução ao TenthMatrix WSL Proxywslproxy.org
Assista: tour pelo WAF do WSL Proxy
Assistir
Assistir no YouTube: Assista: tour pelo WAF do WSL Proxywslproxy.org/waf
Como o proxy funciona
Como um manual de soluções: corresponder uma vez, decidir a cada requisição e então fazer proxy ou proteger. O plano de controle nunca precisa reiniciar a borda para mudanças comuns de regras.
A requisição chega a um POP
Navegadores, APIs e agentes chegam a uma borda do TenthMatrix WSL Proxy (Docker, POP bare-metal com Ansible ou ingress Helm em k3s). O OpenResty aceita o TLS e entra no caminho crítico em Lua.
Corresponder a uma regra de roteamento
gateway_ack.lua carrega o host virtual e avalia regras ao vivo do disco ou do Redis: caminho, IP, país, JWT, S3, cookie e mais. Prioridade e especificidade escolhem a vencedora — sem recarregar o nginx.
Pipeline: limite de taxa → WAF → resposta
O pipeline do gateway aplica os limites de taxa, depois o motor WAF (etapas + assinaturas), e então gateway_resp.lua aplica a ação de resposta e os timeouts do balanceador.
Decidir o resultado
Resultados típicos: 305 proxy reverso para um upstream, redirecionamento 301/302, bloqueio com HTML estático, desafio CAPTCHA ou bloqueio WAF 403 com cabeçalhos de ID de suporte.
Balancear e observar
Para respostas de proxy, balancer_by_lua aplica balanceamento ponderado, RR, canary, sticky ou least-conn. Saúde, métricas e estatísticas de tráfego alimentam as operações e os hooks de logs com IA.
Operadores e agentes conduzem a configuração
Pessoas usam a interface de administração / CLI; agentes usam REST ou ferramentas MCP para CRUD de servidores, regras e vínculos de WAF — a mesma interface, com pull/push compatível com GitOps.
| Code | Significado |
|---|---|
| 305 | Proxy reverso para o upstream (caminho principal do gateway) |
| 301 / 302 | Redirecionamento |
| 200 HTML | Bloqueio ou página intermediária estática / com marca |
| CAPTCHA | Desafio antes de continuar |
| 403 WAF | Bloqueado pelo WAF com cabeçalhos X-WAF-* e X-Support-ID |
Principais recursos do produto em detalhe
Tudo o que você precisa para uma borda governada: roteamento, segurança, cache CDN, entrega multi-POP e um plano de controle que pessoas e agentes podem operar.
Regras de roteamento dinâmicas
Correspondência por caminho, IP, país, claims JWT, chaves no estilo S3 e cookies. As ações incluem proxy reverso, redirecionamento, respostas HTML e CAPTCHA. As regras são ordenadas por prioridade com desempate por especificidade, então a rota mais precisa vence sem reiniciar o nginx.
Engenharia de tráfego
Balanceamento ponderado, round-robin, canary por cabeçalho, sessões sticky por cookie e least-conn. Promova ou reverta backends pelo plano de controle quando um canary parecer saudável — ou retire-o com uma única ação.
Motor WAF empresarial v2
Pacotes de políticas se vinculam por domínio, serviço e rota. As etapas cobrem listas de métodos permitidos, bloqueio por tipo de arquivo, listas de IP/geo, política de algoritmos JWT, perfis de corpo JSON, velocidade de força bruta e segurança positiva OpenAPI — além de assinaturas de ataque governadas e pontuação de anomalias. Modos de bloqueio ou transparente (monitoramento).
CDN e cache de borda
Cache estático de borda, cache opcional de blobs Docker e hooks do Varnish oferecem uma camada tipo CDN na frente das origens — ideal para sites de marketing, documentação de APIs e entrega de artefatos junto ao tráfego do API gateway.
SSL e HTTPS
auto-ssl / Let’s Encrypt, JSON de SSL por domínio e políticas de HTTPS forçado para que cada host virtual termine o TLS corretamente no POP.
Multi-POP + DNS
Declare locais de borda e provisione registros A no Cloudflare com proteções. Um padrão comum em produção é POP público → NodePort do k3s → Helm wslproxy-ingress → pods da app.
Plano de controle
Painéis React Admin e Next.js, REST com Swagger, ferramentas MCP para Claude/Cursor e a imagem wslproxy-cli (ghcr.io/bwalia/wslproxy-cli) para fluxos pull/push/diff/verify.
Implante em qualquer lugar
Docker Compose para laboratórios, Ansible para POPs bare-metal ou em VM e charts Helm de ingress controller para k3s / Kubernetes — uma única interface de produto em todos os ambientes.
Observabilidade
/health, /healthz, /ready, Prometheus /metrics, traffic stats, structured WAF security logs, and AI log analysis hooks for SRE teams.
Regras e aplicação do WAF
O WAF roda no caminho da requisição do OpenResty (inspirado em padrões de WAF empresarial para NGINX). É fail-open por padrão para que um bug no WAF não derrube o site, explicável em cada bloqueio e compatível com listas simples de regras v1. Para um tour guiado e uma análise aprofundada, veja as leituras relacionadas abaixo — ou assista ao vídeo do WAF nesta página.
Pipeline no caminho da requisição
- rewrite_by_lua: gateway_ack.lua seleciona a regra de roteamento
- gateway_pipeline.execute(): limite de taxa → WAF → continuar
- waf_engine.inspect(): carrega a política, resolve o vínculo, executa as etapas e depois as assinaturas
- Ao bloquear: 403 + X-WAF-Block, X-WAF-Rule, X-WAF-Violation, X-Support-ID
Pipeline de etapas (antes das assinaturas)
| Code | Etapa | Detalhe |
|---|---|---|
| VIOL_METHOD | Lista de métodos permitidos | Apenas métodos HTTP permitidos (por exemplo, GET, POST, HEAD, OPTIONS). |
| VIOL_FILETYPE | Bloqueio por tipo de arquivo | Bloqueia extensões sensíveis como .env, .sql, .bak, .git, .pem. |
| VIOL_IP_DENY / VIOL_GEO | Listas de IP e geo | Permite/bloqueia CIDRs e bloqueia países via base de dados tipo IP2Location. |
| VIOL_JWT_ALG | Política de algoritmos JWT | Bloqueia algoritmos fracos (none, HS256); exige RS256/ES256 quando necessário. |
| VIOL_JSON_SIZE / DEPTH | Perfil de corpo JSON | Limita a profundidade do JSON e o tamanho do corpo para evitar abuso do parser. |
| VIOL_BRUTE_FORCE | Velocidade de força bruta | Janelas deslizantes por caminho (por exemplo, /api/login) indexadas por IP. |
| VIOL_OPENAPI_* | Segurança positiva OpenAPI | Permite apenas combinações de caminho+método declaradas (caminhos com template). |
Regras de assinaturas e governança
Cada assinatura tem um ID estável (a unidade endereçável), categoria/conjunto, severidade, alvo de correspondência (url, args, body, headers, cookies, UA ou all), padrão regex ou de texto, ação (block ou monitor) e pontuação de anomalia.
disable
signatures.disable ignora uma regra por completo.
stage
signatures.stage apenas gera alarmes até um timestamp — um rollout seguro que nunca soma à pontuação de anomalia enquanto está em staging.
conjuntos de assinaturas
Alterne conjuntos inteiros (por exemplo, SET_SQLI) entre bloqueio e alarme sem reescrever cada regra.
limite de anomalia
Pontuação acumulada ≥ limite dispara VIOL_ANOMALY_SCORE mesmo que nenhuma assinatura sozinha bloqueasse.
Precedência de vínculos
Vence o mais específico: sobrescrita de rota → waf_mode_override por servidor → enforcementMode padrão da política (blocking ou transparent/monitor). Cada achado registra qual vínculo venceu, para que os logs respondam “por que isto foi bloqueado?”
Bloqueio
Violações retornam 403 com ID de suporte e página de bloqueio com marca opcional.
Transparente / monitoramento
Violações apenas geram alarmes e logs — ideal para dry-run e staging.
Agents Gateway e MCP Gateway
A TenthMatrix está levando o WSL Proxy para a era dos agentes. A mesma borda que fica na frente das APIs HTTP vai governar como agentes e clientes do Model Context Protocol (MCP) acessam ferramentas e backends.
In progress
MCP Gateway (em desenvolvimento)
Uma porta de entrada governada na frente de servidores MCP externos — ponte de autenticação, listas de permissão/bloqueio de ferramentas/métodos, auditoria de tools/call e limites de taxa por ferramenta. Os clientes nunca têm os tokens do upstream.
In progress
Agents Gateway (em desenvolvimento)
Políticas, roteamento e observabilidade para tráfego multiagente — para que frotas de agentes cheguem às origens pela mesma borda do TenthMatrix WSL Proxy que suas APIs e cargas CDN.
Available
Interface de gerenciamento MCP (disponível)
O WSLProxy já expõe sua própria interface de administração como ferramentas MCP para Claude, Cursor e outros agentes — configure regras e inspecione a borda sem sair do seu IDE.
Arquitetura da solução
Clientes e agentes chegam a um POP do TenthMatrix WSL Proxy. A borda aplica regras ao vivo, WAF e cache, e depois balanceia para as origens. Os operadores controlam tudo pela interface de administração, REST, MCP ou CLI.
POP de borda
Caminho crítico OpenResty + Lua: corresponder regras, responder, balancear backends.
Configuração ao vivo
Regras, WAF e divisões de tráfego do disco ou do Redis — sem recarregar o nginx para mudanças do dia a dia.
Plano de controle
Interface de administração, REST, MCP e wslproxy-cli para pessoas e agentes.
Origens
APIs, serviços em k3s, sites estáticos e futuros upstreams MCP / de agentes.
Continuar no site do produto
Acesse wslproxy.org para demos, documentação e as versões mais recentes do TenthMatrix WSL Proxy.
Obter o TenthMatrix WSL Proxy
Conheça o produto em wslproxy.org, leia a análise aprofundada do WAF na TenthMatrix ou fale conosco sobre implantações de borda, CDN, WAF e gateway de agentes.