> For the complete documentation index, see [llms.txt](https://www.axisnow.io/zh/docs/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://www.axisnow.io/zh/docs/edge/policies/rate-limiting.md). # 速率控制 按选定维度统计请求频率并在超限时处置 速率控制（也叫限速、限流，Rate Limiting）在边缘节点上统计每个来源在一段时间内的请求次数，超过您设定的阈值时执行缓解动作。它针对的是靠单个请求的特征识别不出来、只有按频率统计才会显形的滥用：撞库、刷接口、爬虫、失控的客户端重试，以及人机验证挡不住的 API 调用。 ## 在防护体系里的位置 速率控制是[纵深安全防护](/zh/docs/edge/architecture/security.md#layer-5-rate-limiting)的第 5 层，也是**策略**下的一个插件。在一次请求的处理链路上，它排在真实客户端 IP、认证与授权、通用访问控制之后，缓存之前：
若已启用，先于速率控制执行对速率控制的意义
真实客户端 IP计数维度里的「客户端 IP 地址」是它还原出的真实地址。边缘前有 CDN 或负载均衡时必须先配好，否则所有访客算在同一个 IP 上；IP 封禁对经代理转发的流量不生效
认证与授权启用后，认证失败的请求在这一层就被拒绝，不会进入限速计数
通用访问控制启用后，被访问控制拒绝的请求不进入限速；访问控制的「跳过」动作可以选择绕过速率控制插件，这是给可信来源（监控探针、合作伙伴、搜索引擎）豁免限速的方式
速率控制在缓存之前判定，所以命中缓存的请求同样被计数、同样会被限制。 三个插件的分工可以概括为一句话：认证与授权按身份，通用访问控制按请求特征，速率控制按频率。速率控制本身不识别身份，它只按您选定的维度计数；维度都直接取自请求（IP、路径、Cookie、请求头、TLS 指纹等），其中「客户端 IP 地址」在启用真实客户端 IP 插件后才是还原出的真实地址。前面的层一个都不开，按 IP 和路径的限速照样工作。 ## 一条规则做什么 每条规则回答四个问题：哪些请求进入这条规则（条件，可选只数满足某种响应的请求）；按什么来数（计数 Key）；N 秒内不超过多少次（限速阈值）；超过了怎么办（限速动作：观察、阻断、IP 封禁、挑战）。多条规则按优先级依次评估，每条独立计数、独立处置。 ## 下一步
页面内容
工作原理规则求值、计数方式、命中与超限的区别、计数作用域、四种动作的语义、响应头
配置项条件、计数 Key 的全部维度与预设、响应计数条件、阈值、四种动作各自的子配置、优先级与保存
防护场景按攻击面整理的可直接套用的规则参数
洞察与日志规则列表上的指标、洞察页每个指标的定义、IP 封禁记录、日志检索
常见问题使用中的疑问与排错
--- # Agent Instructions This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com. ## Querying This Documentation If you need additional information that is not directly available in this page, you can query the documentation by asking a question. Perform an HTTP GET request on the following URL with the `ask` and `goal` query parameters: ``` GET https://www.axisnow.io/zh/docs/edge/policies/rate-limiting.md?ask=&goal= ``` `ask` is the immediate question: it should be specific, self-contained, and written in natural language. `goal` is what the user is ultimately trying to achieve, the reason they need the answer. Sharing it helps GitBook give you a better, more relevant answer. A goal is most helpful when it describes the outcome the user wants rather than restating the question. For example, with `ask=how do I create an API token`, a goal like `automate deployments from our CI pipeline` lets GitBook tailor the answer to that use case. The response will contain a direct answer to the question and relevant excerpts and sources from the documentation. Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.