需通过Dify管理API的PUT请求精确配置限流参数：免费版仅支持API调用，专业版及以上才可修改；user_id、rate（如"300 requests/minute"）、burst为必填字段；burst应略高于峰值请求数且不大于rate的20%，否则被截断。
☞☞☞AI 智能聊天, 问答助手, AI 智能搜索, 多模态理解力帮你轻松跨越从0到1的创作门槛☜☜☜
你需要在Dify中精确控制某个API密钥的每分钟调用次数、突发容量和令牌补充速率，避免因配置不当导致服务不可用或资源浪费。
确认当前限流配置来源
先判断你正在使用的限流策略是否由平台默认策略、租户级配置或用户级API密钥绑定策略生效。免费版用户无法通过管理界面修改限流参数，【所有自定义配置必须通过Dify管理API发起PUT请求】；专业版及以上用户才拥有调用该API的权限。
执行curl命令检查当前账户是否具备配置能力：
curl -I https://api.dify.ai/v1/settings/rate-limit -H "Authorization: Bearer YOUR_ADMIN_API_KEY"
若返回403，则说明当前密钥无管理权限，需切换为管理员密钥；若返回404，表示该接口未启用（常见于自部署实例未开启管理API）。
设置用户级限流参数
这是最常用且影响最直接的配置方式，适用于为特定用户（如外部合作方）分配独立配额。
方法一：使用标准JSON结构提交
发送PUT请求至/v1/settings/rate-limit，Body中必须包含user_id、rate和burst三个字段：
{"user_id": "usr-abc123", "rate": "300 requests/minute", "burst": 50}
注意：rate字段格式必须严格为“数字 + 空格 + requests/时间单位”，支持minute或second；写成"300/min"或"300r/m"将导致400错误。
方法二：通过Python脚本动态构造并校验
先用requests库发送预检请求，检查X-RateLimit-Limit头是否允许写入；再构造payload，确保burst值不大于rate数值的20%（否则系统会静默截断为上限值）。
配置应用级突发容量（burst）
突发容量决定你的应用能否应对短时流量高峰，比如批量导入任务或定时同步触发的集中调用。
第一步：计算合理burst值
burst应略高于单次批量操作的最大请求数。例如，一次同步需发起47个请求，则burst至少设为48；设为47会导致第47次请求被拒绝——因为令牌桶初始为空，首次请求会消耗1个令牌，剩余46个可用，第47次实际是第47次消耗，超出burst边界。
第二步：更新配置
在原有rate配置基础上，仅修改burst字段并重发PUT请求。不要省略rate字段，否则系统将回退到默认值（免费版为60 requests/minute）。
第三步：验证burst生效
用同一API密钥连续发起burst+1次请求（间隔X-RateLimit-Remaining是否在前burst次中递减至0，而非提前归零。
调整令牌补充速率（refill_rate）
refill_rate控制令牌恢复速度，单位是“令牌数/秒”，直接影响请求恢复的平滑度。
方法1：匹配业务节奏设定
若你的业务每5秒稳定发起1次请求，refill_rate设为0.2即可；若希望10秒内补满burst容量，则refill_rate = burst ÷ 10。例如burst=50 → refill_rate=5。
方法2：避免反模式配置
refill_rate不能大于rate数值除以60（即每秒平均令牌数）。例如rate="60 requests/minute" → 最大refill_rate=1；设为1.1将被系统强制截断为1，且不报错、不警告。
提交时需将refill_rate作为顶层字段与rate、burst同级嵌入JSON，不可放在子对象中。
查看并验证最终配置效果
调用任意Dify API接口（如/v1/completions），检查响应头：
X-RateLimit-Limit: 300
X-RateLimit-Remaining: 298
X-RateLimit-Reset: 1734794280
若X-RateLimit-Limit与你配置的rate数值一致，且X-RateLimit-Remaining初始值等于Limit减去本次请求消耗数（通常为1），说明配置已实时生效。重置时间戳为UTC秒级时间戳，可用date -d @1734794280本地验证。
