API هوش مصنوعی در ایران؛ راهنمای دسترسی، تست و انتخاب امن

پاسخ سریع: برای انتخاب API هوش مصنوعی در ایران نباید فقط بازشدن سایت یا پاسخ Endpoint را ملاک قرار داد. دسترسی معتبر یک زنجیره کامل از DNS و TLS تا ثبت‌نام، دریافت API Key، مشاهده مدل و اجرای درخواست واقعی است. وضعیت هر Provider باید با Evidence تاریخ‌دار، روش تست روشن و بدون افشای Secret ثبت شود. سیاست رسمی منطقه‌ای نیز از نتیجه فنی جداست.

وضعیت به‌روز و منابع هر Provider در کاتالوگ APIهای رایگان LLM منتشر می‌شود. برای دیدن داده خام، ثبت Issue و مشارکت در اعتبارسنجی به مخزن GitHub پروژه مراجعه کنید.

چرا ارزیابی دسترسی از ایران پیچیده است؟

یک سرویس ممکن است در سطح شبکه قابل دسترسی باشد، اما ثبت‌نام را برای منطقه خاص نپذیرد. ممکن است حساب ساخته شود ولی API Key صادر نشود. گاهی Endpoint عمومی پاسخ می‌دهد، اما مدل هنگام Inference خطای منطقه‌ای برمی‌گرداند. همچنین نتیجه ممکن است بین ISP، ASN، IPv4، IPv6 یا زمان‌های مختلف متفاوت باشد.

به همین دلیل عبارت‌هایی مانند «باز است»، «کار می‌کند» یا «فیلتر نیست» برای یک Catalog فنی کافی نیستند. هر ادعا باید دقیقاً مشخص کند کدام مرحله آزمایش شده است.

هشت لایه بررسی دسترسی

۱. DNS

نام دامنه باید Resolve شود. خطای DNS می‌تواند محلی، موقت یا مربوط به Route باشد. نتیجه DNS به‌تنهایی چیزی درباره مجازبودن استفاده یا کارکرد API نمی‌گوید.

۲. TLS و اتصال HTTPS

Handshake باید موفق باشد و Certificate معتبر دریافت شود. Timeout یا خطای TLS می‌تواند از مسیر شبکه، IPv6، تنظیمات سرویس یا اختلال موقت ناشی شود.

۳. وب‌سایت و مستندات

بازشدن Website و Docs برای مطالعه مفید است، اما هنوز استفاده از API را ثابت نمی‌کند. بعضی Providerها وب‌سایت عمومی دارند ولی Console آن‌ها محدود است.

۴. ثبت‌نام

باید بررسی شود فرم ثبت‌نام، تأیید ایمیل، CAPTCHA و قوانین حساب برای کاربر قابل انجام هستند. نیاز به شماره تلفن، کارت بانکی یا هویت خاص باید صریح ثبت شود.

۵. دریافت Credential

ورود موفق به Dashboard به معنی صدور API Key نیست. باید مشخص شود کاربر می‌تواند یک کلید معتبر با Scope مناسب بسازد.

۶. فهرست مدل

برخی حساب‌ها ساخته می‌شوند ولی مدل رایگان یا Endpoint موردنظر فعال نیست. مشاهده مدل مجاز مرحله جداگانه است.

۷. Inference واقعی

معتبرترین تست عملی، ارسال درخواست کوچک به مدل و دریافت پاسخ قابل Parse است. پاسخ 401 فقط Reachability را نشان می‌دهد. پاسخ 403 ممکن است مربوط به Region، Credential یا Policy حساب باشد و باید با Context تفسیر شود.

۸. سیاست رسمی

ممکن است درخواست فنی در یک زمان موفق شود، اما Provider در Terms یا فهرست Regionها ایران را پشتیبانی نکند. نتیجه فنی نباید سیاست رسمی را حذف یا بازنویسی کند.

وضعیت‌های کاتالوگ چگونه تفسیر می‌شوند؟

• verified_working: درخواست واقعی با روش و تاریخ مشخص موفق بوده است.
• verified_blocked: مانع فنی قابل بازتولید با Evidence کافی ثبت شده است.
• signup_blocked: شبکه یا Endpoint ممکن است قابل دسترسی باشد، اما ساخت حساب یا دریافت Credential مانع دارد.
• officially_unsupported: منبع رسمی منطقه را پشتیبانی نمی‌کند.
• unknown: Evidence کافی برای نتیجه قطعی وجود ندارد.

unknown نه مثبت است و نه منفی. این وضعیت باید تا انجام تست معتبر حفظ شود.

نمونه تست امن Endpoint

برای درخواست واقعی باید از Credential مجاز خودتان استفاده کنید. کلید را در متغیر محیطی نگه دارید و خروجی عمومی را Sanitized کنید.

import os
import time
from openai import OpenAI

client = OpenAI(
    api_key=os.environ["LLM_API_KEY"],
    base_url=os.environ["LLM_BASE_URL"],
    timeout=20,
    max_retries=0,
)

started = time.perf_counter()
response = client.chat.completions.create(
    model=os.environ["LLM_MODEL"],
    messages=[{"role": "user", "content": "فقط کلمه OK را بنویس."}],
    max_tokens=8,
)
elapsed_ms = round((time.perf_counter() - started) * 1000)

print({
    "success": True,
    "latency_ms": elapsed_ms,
    "model": response.model,
})

در گزارش عمومی فقط Provider، تاریخ، نوع مسیر، Country، نتیجه کلی، Status code و مدل را ثبت کنید. API Key، Cookie، ایمیل، IP کامل، شناسه حساب، Header احراز هویت و متن حساس نباید منتشر شوند.

چه چیزهایی Evidence کافی نیستند؟

موارد زیر به‌تنهایی اثبات استفاده موفق نیستند:

• Ping یا DNS؛
• بازشدن صفحه اصلی؛
• دریافت 401 از API؛
• مشاهده Docs؛
• پاسخ موفق از یک Monitoring خارجی؛
• تجربه بدون تاریخ؛
• گزارش بدون مدل و Endpoint؛
• Screenshot شامل اطلاعات حساب؛
• موفقیت با مسیر شبکه متفاوت بدون ذکر آن؛
• ادعای شخص ثالث بدون قابلیت بازتولید.

این داده‌ها می‌توانند سرنخ باشند، اما نباید وضعیت نهایی را تغییر دهند.

تفاوت مسیر مستقیم و مسیر مجاز دیگر

اگر یک تست از مسیر مستقیم ایران انجام شده و تست دیگر از شبکه سازمانی یا VPN مجاز است، نتایج باید جدا ذخیره شوند. خروجی مسیر دوم نمی‌تواند جایگزین Evidence مسیر مستقیم باشد. همچنین Country خروجی، زمان و روش باید ثبت شود.

این پروژه دستور دورزدن محدودیت‌های منطقه‌ای ارائه نمی‌کند. کاربر باید قوانین Provider، مقررات محل خود و سیاست سازمان را رعایت کند.

انتخاب Provider برای پروژه ایرانی

بررسی ثبت‌نام

قبل از نوشتن کد اصلی، مسیر Signup را آزمایش کنید. اگر Credential قابل دریافت نیست، Reachability API برای پروژه عملی ارزش محدودی دارد.

بررسی سهمیه

سهمیه روزانه، دقیقه‌ای، Token و هم‌زمانی را مقایسه کنید. اینترنت ناپایدار می‌تواند Retry ایجاد کند و مصرف را بالا ببرد.

بررسی زبان فارسی

چند Prompt نماینده با متن رسمی، محاوره، اعداد و نیم‌فاصله بسازید. کیفیت فارسی را از شهرت عمومی مدل جدا بسنجید.

بررسی Privacy

داده حساس را به Free Gateway ناشناس ارسال نکنید. Retention، Training policy و محل پردازش را بخوانید.

بررسی پایداری

یک تست موفق برای SLA کافی نیست. چند اجرای زمان‌بندی‌شده داشته باشید و خطا، Latency و تغییر مدل را ثبت کنید.

معماری مقاوم در برابر تغییر دسترسی

برای کاهش ریسک:

1. Provider را پشت Adapter قرار دهید.
2. Base URL و مدل را در Environment نگه دارید.
3. Timeout کوتاه و Retry محدود داشته باشید.
4. خطای Region را از Authentication جدا کنید.
5. Provider جایگزین تعریف کنید.
6. درخواست‌های دارای اثر جانبی را Idempotent کنید.
7. متریک سلامت را بدون Prompt حساس ثبت کنید.
8. وضعیت Catalog را دوره‌ای بررسی کنید.
9. تغییرات مدل را با Contract Test بسنجید.
10. وابستگی به یک Trial موقت را کاهش دهید.

خطاهای رایج

• استفاده از یک Status code بدون Context؛
• مخلوط‌کردن نتیجه مستقیم و VPN؛
• ثبت API Key در Screenshot؛
• فرض اینکه Signup همیشه مانند گذشته است؛
• تغییر وضعیت براساس یک تجربه قدیمی؛
• یکی‌دانستن سیاست رسمی و Reachability؛
• نادیده‌گرفتن تفاوت ISP یا ASN؛
• استفاده از مدل نامعتبر در تست؛
• Retry زیاد و اشتباه‌گرفتن 429 با Block؛
• انتشار جزئیات زیرساخت یا حساب.

گزارش استاندارد چه فیلدهایی دارد؟

یک گزارش Sanitized بهتر است شامل این موارد باشد:

• Provider؛
• تاریخ و ساعت UTC؛
• کشور و نوع مسیر؛
• مستقیم یا مسیر دیگر؛
• مرحله تست‌شده؛
• Endpoint کلی بدون Secret؛
• مدل؛
• HTTP status؛
• نتیجه قابل Parse؛
• Latency تقریبی؛
• توضیح محدودیت؛
• تأیید حذف اطلاعات حساس.

اگر نتیجه نامطمئن است، همان ابهام ثبت شود و وضعیت قطعی ساخته نشود.

پرسش‌های متداول

آیا بازشدن API از ایران یعنی استفاده مجاز است؟

خیر. Reachability فنی و سیاست رسمی دو موضوع جدا هستند. Terms و Regionهای پشتیبانی‌شده را بررسی کنید.

آیا پاسخ 401 نشانه کارکردن سرویس است؟

فقط نشان می‌دهد Endpoint پاسخ داده است. برای اثبات استفاده، Credential معتبر و Inference موفق لازم است.

چرا نتیجه دو اینترنت متفاوت است؟

Routing، DNS، IPv4/IPv6، ASN و اختلال موقت می‌توانند متفاوت باشند. هر مسیر باید جدا ثبت شود.

چگونه بدون افشای اطلاعات گزارش بدهم؟

Secretها و شناسه‌های حساب را حذف کنید. فقط داده فنی لازم، تاریخ و نتیجه کلی را منتشر کنید.

بهترین API برای ایران کدام است؟

این وضعیت پویاست. Providerهایی را در اولویت بگذارید که Evidence مستقیم تازه، Signup قابل انجام، سهمیه روشن و کیفیت مناسب پروژه دارند. سپس تست مجاز خودتان را انجام دهید.

راهنماهای مرتبط

• راهنمای API رایگان هوش مصنوعی — نمای کلی APIهای رایگان هوش مصنوعی
• لیست API رایگان LLM — مقایسه کامل همه APIهای رایگان LLM
• GPT API رایگان بدون کارت بانکی — دسترسی GPT بدون پرداخت
• جایگزین OpenAI API — گزینه‌های سازگار با OpenAI

جمع‌بندی

ارزیابی API هوش مصنوعی در ایران باید دقیق، لایه‌ای و تاریخ‌دار باشد. Website، Signup، Credential، Model و Inference را جدا ببینید. هیچ نتیجه‌ای را از روی حدس یا یک Probe ناقص به کاتالوگ منتقل نکنید. برای آخرین وضعیت به کاتالوگ زنده مراجعه کنید و گزارش Sanitized را در GitHub پروژه ثبت کنید.