---
read_when:
    - به‌روزرسانی رفتار یا مقادیر پیش‌فرض تلاش مجدد ارائه‌دهنده
    - اشکال‌زدایی خطاهای ارسال ارائه‌دهنده یا محدودیت‌های نرخ درخواست
summary: سیاست تلاش مجدد برای فراخوانی‌های خروجی ارائه‌دهنده
title: سیاست تلاش مجدد
x-i18n:
    generated_at: "2026-07-27T14:02:40Z"
    model: gpt-5.6
    postprocess_version: locale-links-v1
    prompt_version: 32
    provider: openai
    source_hash: 9be2bcb5af829b90042bfcbc5c0e5f5cc5a3cb03dd5472737c80fa0f15803361
    source_path: concepts/retry.md
    workflow: 16
---

## اهداف

- تلاش مجدد به‌ازای هر درخواست HTTP، نه به‌ازای هر جریان چندمرحله‌ای.
- با تلاش مجدد فقط برای مرحلهٔ جاری، ترتیب حفظ می‌شود.
- از تکرار عملیات غیرهم‌توان جلوگیری می‌شود.

## مقادیر پیش‌فرض

| تنظیم                 | مقدار پیش‌فرض |
| --------------------- | ------------- |
| تعداد تلاش‌ها         | 3             |
| سقف حداکثر تأخیر      | 30000 ms      |
| نوسان تصادفی          | 0.1 (10%)     |
| حداقل تأخیر Telegram  | 400 ms        |
| حداقل تأخیر Discord   | 500 ms        |

## رفتار

### ارائه‌دهندگان مدل

- OpenClaw مدیریت تلاش‌های مجدد کوتاه و معمول را به SDKهای ارائه‌دهندگان واگذار می‌کند.
- برای SDKهای مبتنی بر Stainless مانند Anthropic و OpenAI، پاسخ‌های قابل تلاش مجدد (`408`، `409`، `429` و `5xx`) می‌توانند شامل `retry-after-ms` یا `retry-after` باشند. وقتی این زمان انتظار بیش از 60 ثانیه باشد، OpenClaw مقدار `x-should-retry: false` را تزریق می‌کند تا SDK خطا را بلافاصله آشکار کند و سازوکار جایگزینی مدل بتواند به نمایهٔ احراز هویت دیگری یا مدل پشتیبان تغییر مسیر دهد.
- سقف را با `OPENCLAW_SDK_RETRY_MAX_WAIT_SECONDS=<seconds>` بازنویسی کنید. آن را روی `0`، `false`، `off`، `none` یا `disabled` تنظیم کنید تا SDKها بتوانند زمان‌های انتظار طولانی `Retry-After` را درون خود رعایت کنند.

### Discord

- در خطاهای محدودیت نرخ (HTTP 429)، پایان مهلت درخواست، پاسخ‌های HTTP 5xx و اختلالات موقت انتقال مانند شکست جست‌وجوی DNS، بازنشانی اتصال، بسته‌شدن سوکت و شکست دریافت، دوباره تلاش می‌کند.
- در صورت موجود بودن از `retry_after` متعلق به Discord استفاده می‌کند؛ در غیر این صورت، از عقب‌نشینی نمایی استفاده می‌کند.

### Telegram

- در خطاهای موقت (429، پایان مهلت، اتصال/بازنشانی/بسته‌شدن، موقتاً دردسترس‌نبودن) دوباره تلاش می‌کند.
- در صورت موجود بودن از `retry_after` استفاده می‌کند؛ در غیر این صورت، از عقب‌نشینی نمایی استفاده می‌کند.
- برای خطاهای تجزیهٔ HTML/Markdown دوباره تلاش نمی‌شود؛ در نخستین تلاش، به متن ساده بازمی‌گردند.

## پیکربندی

سیاست تلاش مجدد هر ارائه‌دهنده را در `~/.openclaw/openclaw.json` تنظیم کنید:

```json5
{
  channels: {
    telegram: {
      retry: {
        attempts: 3,
        minDelayMs: 400,
        maxDelayMs: 30000,
        jitter: 0.1,
      },
    },
    discord: {
      retry: {
        attempts: 3,
        minDelayMs: 500,
        maxDelayMs: 30000,
        jitter: 0.1,
      },
    },
  },
}
```

## نکات

- تلاش‌های مجدد به‌ازای هر درخواست اعمال می‌شوند (ارسال پیام، بارگذاری رسانه، واکنش، نظرسنجی، برچسب).
- جریان‌های ترکیبی مراحل تکمیل‌شده را دوباره اجرا نمی‌کنند.

## مرتبط

- [جایگزینی مدل](/fa/concepts/model-failover)
- [صف فرمان](/fa/concepts/queue)