商店現已上線

我們打造用於網站、AI 智慧體和 LLM 訓練的 Workstation AI 機器——線上配置併購買。

獲取同行價格
AI 產品
AI 實驗室OpenAI 智慧體Claude 代理Grok BotWorkstation AI 原生 CRM營銷所有產品
AI 解決方案
應用型 AIAI 智慧體生成式 AIAI 自動化AI 技能提升中小企業 AI 套餐企業 AI 實驗室AI 工作站NVIDIA 硬體與軟體NVIDIA 加速計算私有 AIGPU 私有云GPU 叢集邊緣 AI行業 AI
AI 服務
平臺現代化數字工程資料基礎與 AI自主運營AI 諮詢DevOps 自動化網路安全軟體開發智慧體構建MLOps 搭建GPU 租賃GPU 私有云
關於我們
公司我們的故事合作伙伴客戶案例
AI 資料中心
AI 資料中心GPU 私有云GPU 叢集GPU 租賃
AI 洞察Jev 系列基準測試實驗室模型選擇
技術說明
文件
Linux 作業系統UbuntuRed Hat Enterprise LinuxSUSE LinuxAlpine LinuxDebian、Rocky 與 AlmaLinux
AI 雲平臺AWS 與 Amazon BedrockGoogle Cloud 與 Vertex AIMicrosoft Azure 與 AI FoundryGPU 雲與算力市場
私有 AI 資料中心面向律師事務所面向會計師事務所本地部署平臺全面安全的雲
工具Ring PromoterJobshout
新聞
部落格
聯絡我們登入

面向現代企業的 AI 工作站、AI 多智慧體軟體、GPU 基礎設施和智慧代理解決方案。

聯絡我們

AI 解決方案

應用型 AIAI 智慧體生成式 AIAI 自動化AI 技能提升中小企業 AI 套餐企業 AI 實驗室行業 AI

產品

所有產品Workstation AI native CRM 與 ERP營銷OpenAI 智慧體Ring PromoterJobshout

公司

關於我們公司AI 資料中心為什麼選擇Workstation合作伙伴客戶案例定價聯絡TenthMatrix

資源

AI 洞察技術說明文件Linux 作業系統AI 雲平臺私有 AI 資料中心部落格搜尋網站地圖
英國總部
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
台灣辦公室
3F, No. 2-4, Aisi Rd., Ren'ai Dist., Keelung City 200, Taiwan基隆市仁愛區愛四路2之4號3樓週一至週五:上午 9:00 - 下午 6:00 臺灣時間(GMT+8)
+886 926 892 701+32 492 45 67 46

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

隱私資料刪除Cookie服務條款網站地圖

NVIDIA、NVIDIA 標誌、RTX、RTX PRO、Blackwell、CUDA、NVLink、MGX、Omniverse、Spectrum-X、Quantum、BlueField、DGX 與 HGX 為 NVIDIA Corporation 在美國及其他國家的商標及/或註冊商標。AMD、AMD Arrow 標誌、EPYC、Instinct、Ryzen 與 Threadripper 為 Advanced Micro Devices, Inc. 的商標。Dell 與 PowerEdge 為 Dell Inc. 或其子公司的商標。Intel 與 Xeon 為 Intel Corporation 或其子公司的商標。AMAX、AceleMax 與 LiquidMax 為 AMAX Engineering Corporation 的商標。所有其他產品名稱、標誌與品牌均為其各自所有者之財產。我們使用它們僅為識別我們所描述、供應或支援的產品;使用這些名稱並不表示其所有者為我們背書。

Loading 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 WAF — Web Application Firewall

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/