Workstation Logo
产品
AI 实验室OpenAI代理Claude 代理Grok BotWorkstation CRM (WSL CRM)营销全部产品
AI 解决方案
AI 工作站AI SME Packages私有 AIGPU 集群边缘 AI企业 AI 实验室按行业分类的 AI
服务
Platform ModernisationDigital EngineeringData Foundations & AIAutonomous OperationsAI 咨询DevOps 自动化网络安全软件开发智能体构建MLOps 搭建
关于我们
合作伙伴客户案例
文章
文档
WSL ProxyRing PromoterWSL VaultJobshoutSysOps 24/7
博客
联系我们Login
Workstation

面向现代企业的 AI 工作站、AI 多智能体软件、GPU 基础设施和智能代理解决方案。

联系我们

AI 解决方案

AI 工作站AI SME Packages私有 AIGPU 集群边缘 AI企业 AI 实验室按行业分类的 AI

产品

全部产品WSL CRM 与 ERP营销OpenAI代理WSL ProxyRing PromoterWSL VaultJobshoutSysOps 24/7

公司

关于我们为什么选择Workstation合作伙伴客户案例价格联系

资源

文章文档博客搜索网站地图
英国办公室
77-79 Marlowes, Hemel Hempstead HP1 1LF路线指引 — 从 M25 外环伦敦 20 号出口驶出公司编号: 11641870周一至周五:上午 9:00 - 下午 6:00 GMT
+44 7515 356 146
比利时办公室
Workstation SRL, Rue Vanderkindere 34, 1180 Uccle, BrusselsBE 0751.518.683周一至周五:上午 9:00 - 下午 6:00 CET
+32 492 45 67 46
印度办公室
#159 Sector 9, Pocket 1, DDA Flats, 110077 Dwarka, New Delhi
+91 98881 98841

© 2026 Workstation AI。保留所有权利。

隐私Cookie服务条款网站地图

Loading blog...

Home / Blog
DevOpsSecuritySREKubernetesAIAutomation

WSL Proxy WAF: Explainable Web Application Firewall at the Edge

Live policies, stages and signatures on Workstation WSL Proxy — monitor or block, with support IDs on every decision

Balinder Walia2026年9月16日3 min read

Workstation WSL Proxy puts a governed Web Application Firewall on the same live-config edge that routes and caches your traffic. Policies bind per domain and route, run in monitor or block, and every decision names a support ID. Companion deep dive: long article. Product: /wsl-proxy.

Workstation WSL Proxy WAF — Web Application Firewall

Watch: WSL Proxy WAF tour

Workstation WSL Proxy WAF tour

Watch: youtu.be/r10XSonA5JE · Product: wslproxy.org · WAF: wslproxy.org/waf

Bottom line. A WAF you cannot explain is a liability. Workstation WSL Proxy runs stages and governed signatures on the OpenResty request path after rate limiting, fails open by default so a WAF bug cannot take the site down, and returns X-WAF-* headers plus an X-Support-ID when it blocks.

The problem with opaque edge security

Most teams still protect APIs with a static nginx snippet, a shared ModSecurity pack nobody owns, or a cloud checkbox they cannot tune per route. When something breaks at 2 a.m., the ticket says “403 from the edge” with no policy name, no binding, and no safe way to dry-run a change. Reloading the whole POP for every rule change makes security and platform teams fight over the same config file.

Workstation WSL Proxy treats the edge as a product: live JSON and MCP configs for day-to-day routing and WAF, with nginx reloads reserved for listen and SSL changes. Security becomes operable — not a frozen regex list.

Where WAF sits in the pipeline

A request hits a POP. OpenResty accepts TLS and enters the Lua hot path. gateway_ack.lua matches a routing rule. The gateway pipeline then runs rate limits, then the WAF engine, then the response action and balancer. Typical outcomes include reverse-proxy to an upstream, redirect, static HTML, CAPTCHA challenge, or a 403 WAF block with support headers.

Inside the engine the order is fixed: load the policy, resolve the winning binding, run first-class stages, then governed signature matching and anomaly scoring. Each stage is fail-open under protected execution so an internal error logs and allows the request rather than blacking out the site.

What you get today

  • Policy packs bound per virtual host, with route and server overrides for monitor vs block.
  • Eight first-class stages before signatures: method allow-list, filetype deny, HTTP smuggling/desync, IP and geo deny, JWT algorithm policy, JSON depth/size, brute-force velocity, and OpenAPI positive security.
  • Governed signatures with stable IDs (SQLi, XSS, command injection, LFI, SSRF, SSTI, XXE, Log4Shell, Spring4Shell, JWT none, GraphQL introspection, scanner UAs, and related categories), plus disable / stage / set toggles and an anomaly threshold.
  • Explainable blocks: X-WAF-Block, X-WAF-Rule, X-WAF-Violation, X-Support-ID.
  • Layered edge controls on the same POP: per-server rate limit, CAPTCHA (rule status 306), JWT / S3 / cookie rule matches, and geo/IP routing rules independent of WAF stages.
  • Control plane: Admin UI, Swagger REST, MCP tools for Claude/Cursor, and wslproxy-cli pull/push for waf_rules and waf_policies.

Monitor first, then stage, then block

Binding precedence is deliberate: route override wins over per-server override, which wins over the policy default. That lets /preview stay in transparent (monitor/alarm) mode while /api/pay blocks. Signature stage windows alarm only until a timestamp and do not inflate the anomaly score — a safe rollout path before you flip a set to block.

Start in monitor on a staging POP or a low-risk path. Read structured wafsec logs and the events API. Promote sets when the noise is understood. Do not flip production to block without a soak.

Who it is for

Platform, SRE, and security teams who already run OpenResty or need an API gateway and CDN edge that security can actually operate. It is also for teams bringing AI agents to the same edge: MCP tools can already configure and inspect WSLProxy, while Agents Gateway and MCP Gateway integrations remain labelled in progress on the product page — not claimed as live WAF features.

Where to start

  1. Watch the tour above, then open wslproxy.org/waf.
  2. Read the technical article for stages, headers, and rollout practice.
  3. Explore the product overview at /wsl-proxy and the general intro at wslproxy.org.
  4. Engine deep dive: WAF Engine v2 blog · Engine v2 article.

Published by Workstation.

Product site: https://wslproxy.org · WAF: https://wslproxy.org/waf/