---
title: "IP ثابت برای API: خطای مجوز IP چگونه رفع می‌شود؟"
description: "خطای مجوز IP وقتی دیده می‌شود که درخواست شما از نشانی‌ای بیرون برود که نزد سرویس ثبت نشده است. راه یافتن IP خروجی و چهار گزینه ثابت کردن آن را می‌خوانید."
url: https://proxynet.io/fa/blog/static-ip-for-api-access
date: 2026-09-19
author: "Acar Diveroli"
category: "آموزش‌ها, مبانی پروکسی"
lang: fa
---

# IP ثابت برای API: خطای مجوز IP چگونه رفع می‌شود؟

دیشب یکپارچه‌سازی را اجرا کردید: فهرست سفارش‌ها آمد و پیامک رفت. امروز صبح همان کد با همان کلید پیام «مجوز IP لازم است» یا یک `403` خالی برمی‌گرداند. در کد چیزی عوض نشده است. آنچه عوض شده نشانی‌ای است که درخواست شما از آن به اینترنت می‌رود: مودم شب دوباره وصل شده است، همکاری که از خانه کار می‌کند با خط خودش امتحان کرده است یا برنامه به سرور دیگری منتقل شده است. سرویس طرف مقابل هم فقط نشانی‌ای را می‌شناسد که از پیش به او اعلام شده است.

در این نوشته توضیح می‌دهیم مجوز IP در APIها چگونه کار می‌کند، هشدار در چه وضعیت‌هایی ظاهر می‌شود و IP خروجی‌ای را که سرویس واقعاً می‌بیند چگونه پیدا کنید. سپس چهار راه داشتن یک نشانی خروجی ثابت (IP ثابت از ارائه‌دهنده اینترنت، سرور با IP ثابت، ⁦NAT gateway⁩ و پروکسی استاتیک) را در یک جدول مقایسه می‌کنیم. بخش جداگانه‌ای هم به این اختصاص داده‌ایم که در یکپارچه‌سازی‌های پرداخت، سلامت و صورت‌حساب الکترونیکی کدام راه نباید انتخاب شود. در پایان یک نمونه اجراشده با Python و Node.js هست که نشانی خروجی شما را راستی‌آزمایی می‌کند.

> **نکته: پاسخ کوتاه**
>
> APIای که مجوز IP می‌خواهد درخواست را فقط از نشانی‌های ثبت‌شده نزد خودش می‌پذیرد. خطا وقتی دیده می‌شود که درخواست شما از نشانی دیگری بیرون برود: بیشتر خط‌های خانگی و اداری IP پویا دارند و بخشی از آنها پشت CGNAT هم هستند. نخست IP خروجی را روی همان ماشینی که واقعاً درخواست را می‌فرستد پیدا کنید و با نشانی ثبت‌شده مقایسه کنید. راه‌حل ماندگار یک نشانی خروجی است که عوض نمی‌شود. در یکپارچه‌سازی‌هایی که داده حساس جابه‌جا می‌کنند این نشانی باید خط خودتان یا سرور خودتان باشد؛ در محیط‌های آزمایشی و کلاینت‌هایی که داده حساس جابه‌جا نمی‌کنند پروکسی استاتیک هم کار را انجام می‌دهد.

## مجوز IP در APIها چیست؟

مجوز IP (فهرست IPهای مجاز؛ در مستندات بیشتر با نام «IP whitelist» یا «allowlist») یعنی سرویس پیش از نگاه کردن به محتوای درخواست ورودی، آن را بر پایه نشانی مبدأ غربال می‌کند. در پنل سرویس یا در سوابق تیم پشتیبانی آن فهرستی از نشانی‌ها به حساب شما وصل است. اگر درخواست از یکی از نشانی‌های این فهرست بیاید کلید API شما بررسی می‌شود؛ اگر نیاید، حتی با کلید درست هم درخواست رد می‌شود.

این بررسی جای کلید API را نمی‌گیرد، به آن افزوده می‌شود. حتی اگر کلید شما به‌اشتباه در یک مخزن کد بارگذاری شود یا از رایانه یکی از کارکنان نشت کند، کسی که آن را به دست آورده تا وقتی از نشانی شما بیرون نرود نمی‌تواند از آن استفاده کند. چیزی که بررسی می‌شود یک سرآیند HTTP نیست، نشانی سر دیگر اتصال TCP است؛ با افزودن سرآیندی مانند `X-Forwarded-For` نمی‌توانید نشانی مبدأ را عوض کنید.

اینجا دو جهت اغلب با هم اشتباه گرفته می‌شوند. در فهرستی که در نوشته [احراز هویت پروکسی: نام کاربری و رمز یا لیست سفید IP](/fa/blog/proxy-authentication-methods) توضیح داده‌ایم نشانی خود را به **ارائه‌دهنده پروکسی** اعلام می‌کنید و هدف اتصال بدون رمز به پروکسی است. موضوع این نوشته جهت وارونه است: نشانی خود را به **سرویس شخص ثالثی** اعلام می‌کنید که می‌خواهید به داده‌اش برسید. سازوکار یکی است، طرف حساب فرق دارد.

## سرویس‌ها IP خروجی شما را به چه شکل‌هایی می‌خواهند؟

در عمل با سه شکل روبه‌رو می‌شوید.

**ثبت اجباری.** سرویس تا وقتی نشانی شما تعریف نشده باشد دسترسی را باز نمی‌کند. این تعریف را بیشتر وقت‌ها خودتان نمی‌توانید انجام دهید: یک درخواست پشتیبانی باز می‌شود و نشانی در طرف مقابل دستی وارد می‌شود. این شکل در یکپارچه‌سازی با بانک‌ها و نهادهای دولتی و در برخی APIهای بازارگاه‌ها و شرکت‌های حمل رایج است. در برخی سرویس‌ها قاعده فقط برای یک محیط برقرار است، برای نمونه برای محیط آزمایشی و نه برای محیط عملیاتی.

**محدودیت اختیاری.** محدودیت را سرویس روشن نمی‌کند، شما روشن می‌کنید. در پنل بسیاری از سرویس‌های پیام‌رسانی و ایمیل فیلدی هست با این مضمون: «فقط درخواست‌های این نشانی‌ها را بپذیر». در این شکل علت خطا بیشتر وقت‌ها یک تنظیم فراموش‌شده است: محدودیت را خودتان روشن کرده‌اید، سرور جابه‌جا شده و نشانی قدیمی در فهرست مانده است.

**جهت وارونه.** در جریان‌هایی مانند webhook درخواست را سرویس برای شما می‌فرستد و فهرست مجاز را شما نگه می‌دارید: نشانی‌هایی را که سرویس در مستنداتش منتشر کرده است به دیوار آتش خودتان اضافه می‌کنید.

دو شکل نخست اغلب در یک ارائه‌دهنده کنار هم دیده می‌شوند: محیط آزمایشی مجوز IP می‌خواهد و محیط عملیاتی نمی‌خواهد، و در پنل هم محدودیتی اختیاری هست که خودتان روشن می‌کنید. بسیاری از ارائه‌دهندگان پیامک و بازارگاه، این محدودیت را در راهنمای آماده‌سازی خود گامی امنیتی و توصیه‌شده می‌شمارند.

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

## هشدار «مجوز IP لازم است» در چه وضعیتی ظاهر می‌شود؟

این هشدار یک شکل ثابت ندارد. سرویس‌ها همین وضعیت را با کدهای گوناگون اعلام می‌کنند:

- **پیام صریح.** متنی مانند «مجوز IP لازم است» یا «IP not allowed» در بدنه پاسخ. آسان‌ترین حالت برای تشخیص همین است.
- **`403 Forbidden`.** سرور درخواست را فهمیده اما رد کرده است. همان‌طور که [صفحه 403 در MDN](https://developer.mozilla.org/en-US/docs/Web/HTTP/Reference/Status/403) هم می‌گوید، در این کد فرستادن دوباره اطلاعات هویتی نتیجه را عوض نمی‌کند.
- **`401 Unauthorized`.** برخی سرویس‌ها ناهمخوانی نشانی را با همان کد خطای هویتی اعلام می‌کنند. اگر کلید را سه بار تازه کرده‌اید و هنوز `401` می‌گیرید، به نشانی نگاه کنید.
- **`503` یا پایان مهلت.** اگر غربال پیش از برنامه و در دیوار آتش انجام شود ممکن است هیچ پاسخ معناداری نیاید. برخی سرویس‌ها دقیقاً همین رفتار را مستند کرده‌اند: خطای `503` در محیط آزمایشی که در واقع معنایش نبودن مجوز IP است.

وارونه‌اش هم پیش می‌آید: هر `403` مشکل نشانی نیست. برخی APIها درخواستی را که یک سرآیند الزامی، مثلاً `User-Agent`، ندارد با همان `403` رد می‌کنند. پیش از عوض کردن نشانی بدنه پاسخ را بخوانید و درخواست خود را سرآیند به سرآیند با نمونه مستندات مقایسه کنید. خوانش کلی کدهای وضعیت را در نوشته [کدهای وضعیت HTTP در وب اسکرپینگ](/fa/blog/http-status-codes-web-scraping) آورده‌ایم.

## IP خروجی خود را چگونه پیدا کنید؟

نشانی‌ای که به سرویس اعلام می‌شود آن `192.168.x.x` که در تنظیمات شبکه رایانه می‌بینید نیست؛ آن نشانی فقط در شبکه محلی شما معتبر است. سرویس نشانی عمومی‌ای را می‌بیند که مودم یا سرور شما با آن به اینترنت می‌رود. برای یافتن نشانی درست:

1. **روی ماشینی اندازه بگیرید که درخواست را می‌فرستد.** اگر یکپارچه‌سازی روی سرور اجرا می‌شود، نشانی را از ترمینال همان سرور پیدا کنید، نه از مرورگر لپ‌تاپ خودتان.
2. **به یک سرویس پژواک درخواست بفرستید.** `curl https://api.ipify.org` یا `curl https://checkip.amazonaws.com` در پاسخ فقط نشانی‌ای را که می‌بیند برمی‌گرداند.
3. **از همان مسیری اندازه بگیرید که برنامه می‌رود.** اگر برنامه شما از راه پروکسی یا VPN سازمانی بیرون می‌رود، اندازه‌گیری را هم از همان مسیر انجام دهید؛ اندازه‌گیری مستقیم نشانی دیگری نشان می‌دهد.
4. **IPv6 را بررسی کنید.** اگر خط شما IPv6 داشته باشد `curl https://api64.ipify.org` نشانی IPv6 شما را برمی‌گرداند. اگر دامنه سرویس از IPv6 پشتیبانی کند ممکن است درخواست شما از آنجا بیرون برود؛ در این حالت نشانی IPv4 اعلام‌شده اصلاً دیده نمی‌شود.
5. **اندازه‌گیری را تکرار کنید.** همان دستور را پس از راه‌اندازی دوباره مودم و یک بار هم روز بعد اجرا کنید. اگر نشانی عوض می‌شود خط شما پویاست.

## چرا IP ثبت‌شده دیگر جور درنمی‌آید؟

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

- **IP پویا.** در بیشتر خط‌های خانگی و دفترهای کوچک نشانی ممکن است با هر اتصال دوباره مودم یا پایان مهلت اجاره عوض شود. کل این تفکیک را در نوشته [تفاوت IP ثابت و IP پویا](/fa/blog/static-ip-vs-dynamic-ip) توضیح داده‌ایم.
- **CGNAT.** اگر اپراتور یک نشانی عمومی را میان شمار زیادی مشترک تقسیم کند، نشانی‌ای که می‌بینید مال شما نیست و در اتصال بعدی ممکن است به نشانی دیگری از استخر بیفتید. ثبت چنین نشانی‌ای در یک API یعنی باز کردن در به روی مشترکان دیگر همان استخر. راه تشخیص آن در نوشته [CGNAT چیست؟](/fa/blog/what-is-cgnat) آمده است.
- **هات‌اسپات موبایل یا VPN روشن‌مانده.** اتصال اشتراکی از گوشی و کلاینت VPN که روی رایانه روشن مانده است، هر دو درخواست را از نشانی کاملاً متفاوتی بیرون می‌فرستند.
- **بیش از یک نقطه خروج.** کانتینرهایی که خودکار مقیاس می‌گیرند و تابع‌های serverless که به شبکه خصوصی وصل نشده‌اند ممکن است در هر اجرا با نشانی متفاوتی از استخر بزرگ ارائه‌دهنده ابری بیرون بروند. نشانی عمومی‌ای که خودکار به سرور ابری داده می‌شود هم نزد بیشتر ارائه‌دهنده‌ها با خاموش و روشن شدن سرور عوض می‌شود؛ برای ماندگار شدن باید یک نشانی رزرو کنید.

## چهار گزینه برای IP خروجی ثابت

راه‌حل ماندگار نشانی‌ای است که یک بار به سرویس اعلام می‌کنید و عوض نمی‌شود. چهار راه دارد؛ اینکه کدام درست است به این بستگی دارد که کد کجا اجرا می‌شود و چه داده‌ای جابه‌جا می‌کند.

| گزینه | نشانی مال کیست؟ | راه‌اندازی | چه کسی مدیریت می‌کند؟ | چه زمانی انتخاب درست است؟ |
|---|---|---|---|---|
| IP ثابت از ارائه‌دهنده اینترنت | به اشتراک شما وصل است و قراردادش نزد شماست | درخواست از ارائه‌دهنده؛ برای هر خط یک نشانی | شما و ارائه‌دهنده | کد روی رایانه یا سرور داخل دفتر اجرا می‌شود؛ نهاد می‌گوید «نشانی خط خودتان» |
| VPS یا سرور ابری با IP ثابت | برای حسابی که سرور را اجاره کرده رزرو است | سرور راه‌اندازی و برنامه به آن منتقل می‌شود | شما | یکپارچه‌سازی‌های بی‌وقفه، کارهای زمان‌بندی‌شده، برنامه‌هایی که webhook می‌گیرند |
| ⁦NAT gateway⁩ ابری | برای حساب ابری شما رزرو است | همه منابع شبکه خصوصی به یک خروجی هدایت می‌شوند | شما (پیکربندی شبکه لازم است) | چند سرور، کانتینر یا تابع serverless باید از یک نشانی بیرون بروند |
| پروکسی استاتیک (ISP) | مال ارائه‌دهنده پروکسی؛ اختصاصی شما | چند دقیقه؛ فقط نشانی پروکسی در کلاینت نوشته می‌شود | ارائه‌دهنده پروکسی | محیط آزمایش و توسعه، کلاینت‌های API بدون داده حساس، خروج یک تیم پراکنده از یک نشانی |

**IP ثابت از ارائه‌دهنده اینترنت.** سیستم تازه‌ای وارد مسیر نمی‌شود، نشانی خط فعلی شما ثابت می‌شود. نشانی به همان خط بسته است؛ توسعه‌دهنده‌ای که از خانه کار می‌کند یا شعبه‌ای در شهر دیگر نمی‌تواند از آن بیرون برود. گام‌های درخواست در بخش «IP ثابت را چگونه می‌توان گرفت؟» نوشته همراه آمده است.

**سرور با IP ثابت.** اجرای کار پیوسته‌ای مانند همگام‌سازی شبانه موجودی یا دریافت سفارش‌ها روی سروری با نشانی رزروشده، به‌جای رایانه دفتر، هم مشکل نشانی و هم مشکل پیوستگی را حل می‌کند.

**⁦NAT gateway⁩.** به‌جای اعلام نشانی جداگانه برای هر ماشین، همه را به یک در خروج وصل می‌کنید. بنا بر [مستند ⁦NAT gateway⁩](https://docs.aws.amazon.com/vpc/latest/userguide/vpc-nat-gateway.html) در AWS، هنگام ساخت یک ⁦NAT gateway⁩ عمومی یک ⁦Elastic IP⁩ به آن وصل می‌شود و منابع زیرشبکه‌های خصوصی از همین در به اینترنت می‌روند. [مستند ⁦Cloud NAT⁩](https://docs.cloud.google.com/nat/docs/overview) در ⁦Google Cloud⁩ هم می‌گوید وقتی نشانی‌های NAT دستی اختصاص داده شوند می‌توان آنها را با طرف مقصد در میان گذاشت و سرویس‌هایی را مثال می‌زند که فقط از نشانی‌های شناخته‌شده اتصال می‌پذیرند.

**پروکسی استاتیک.** کلاینت شما از یک نشانی پروکسی اختصاصی و تغییرناپذیر به اینترنت می‌رود و همین نشانی را به سرویس اعلام می‌کنید. پویا بودن خط یا قرار داشتن آن پشت CGNAT فرقی نمی‌کند، چون نشانی‌ای که سرویس می‌بیند نشانی پروکسی است. در عوض یک طرف سوم وارد مسیر ترافیک شما می‌شود؛ اینکه کجا پذیرفتنی نیست در بخش بعد آمده است.

## چرا در یکپارچه‌سازی‌های پرداخت، سلامت و صورت‌حساب الکترونیکی از پروکسی استفاده نمی‌شود؟

APIهای پایانه فروش مجازی و مؤسسه‌های پرداخت، سامانه‌های تأیید و ثبت نهادهای سلامت، یکپارچه‌سازی‌های صورت‌حساب و دفتر الکترونیکی و سرویس‌های اعلام نهادهای دولتی دسته جداگانه‌ای هستند. در این یکپارچه‌سازی‌ها **پروکسی شخص ثالث را به‌عنوان نشانی خروجی توصیه نمی‌کنیم**؛ محصول خود ما هم مشمول همین است. راه درست IP ثابت از ارائه‌دهنده اینترنت، نشانی رزروشده سرور خودتان یا ⁦NAT gateway⁩ در حساب ابری شماست. دلیل‌ها:

1. **نشانی ثبت‌شده باید مال شما باشد.** این نهادها نشانی را نه به‌عنوان یک تنظیم امنیتی، بلکه به‌عنوان سندی نگه می‌دارند که می‌گوید «این تراکنش از این سامانه این کسب‌وکار آمده است». نشانی پروکسی مال ارائه‌دهنده است و وقتی سرویس را رها کنید ممکن است به مشتری دیگری داده شود. مجوزی که پاک کردنش در طرف مقابل فراموش شود کاربر تازه آن نشانی را یک گام به حساب شما نزدیک‌تر می‌کند.
2. **یک حلقه به زنجیره افزوده می‌شود.** در HTTPS پروکسی نمی‌تواند محتوای درخواست را ببیند: اتصال با تونل `CONNECT` برقرار می‌شود و رمزنگاری میان شما و API می‌ماند. با این حال پروکسی می‌بیند به کدام سرور، چه زمانی و چه مقدار داده می‌فرستید و در یک خرابی، جریان پرداخت یا صورت‌حساب شما به‌خاطر سامانه‌ای که در اختیار شما نیست می‌ایستد.
3. **قرارداد و ممیزی.** قراردادهای این یکپارچه‌سازی‌ها و مقرراتی که تابع آن هستند از شما می‌خواهند بدانید و بتوانید مستند کنید داده از کدام سامانه‌ها می‌گذرد. شرایط‌نامه نهاد را بخوانید؛ بسیاری از آنها صریحاً شرط می‌کنند که نشانی باید خط یا سرور متعلق به کسب‌وکار شما باشد.
4. **نیازی نیست.** این سامانه‌ها به هر حال سروری می‌خواهند که بی‌وقفه کار کند. اگر سرور دارید نشانی ثابت هم دارید.

همین مرز برای هر یکپارچه‌سازی‌ای که داده شخصی جابه‌جا می‌کند برقرار است: در خطی که هویت مشتری، داده سلامت یا داده کارت در آن جریان دارد نقطه خروج باید زیرساخت خودتان باشد.

## پروکسی استاتیک در چه وضعیتی مناسب است؟

آنچه می‌ماند وضعیت‌هایی است که داده حساس ندارند و راه‌حل سریع می‌خواهند:

- **محیط آزمایش و توسعه.** سرویس برای محیط آزمایشی نشانی می‌خواهد و توسعه‌دهنده‌ها از خانه و با خط‌های پویا کار می‌کنند. به‌جای گرفتن IP ثابت برای خط تک‌تک افراد، تیم از یک نشانی پروکسی بیرون می‌رود و همان به سرویس اعلام می‌شود.
- **تیم پراکنده، یک نشانی مجاز.** تیمی که از سه شهر مختلف با یک ابزار داخلی کار می‌کند ناچار نیست سه نشانی جداگانه به سرویس اعلام کند.
- **دوره گذار.** تا وقتی درخواست IP ثابت یا انتقال به سرور تمام شود یکپارچه‌سازی باید کار کند.
- **کسب‌وکار کوچک پشت CGNAT.** خط با نشانی اشتراکی کار می‌کند و ارائه‌دهنده در آن اشتراک IP ثابت عرضه نمی‌کند.

در هر حال نخست شرایط استفاده سرویس را بخوانید: در سرویسی که شرط کرده درخواست‌ها مستقیم از زیرساخت خودتان بیاید، پروکسی دیگر گزینه نیست.

هنگام انتخاب به دو ویژگی نگاه کنید. نشانی باید **اختصاصی شما** باشد: اگر نشانی اشتراکی را در یک API ثبت کنید، دیگرانی که از همان نشانی استفاده می‌کنند هم از آن غربال می‌گذرند. نشانی باید **استاتیک** باشد؛ نشانی‌های یک استخر چرخشی (rotating) بنا به تعریف عوض می‌شوند. جزئیات این مفهوم در صفحه [پروکسی استاتیک](https://proxynet.io/fa/static-proxy) آمده است. در Proxynet این نیاز را [پروکسی ISP](https://proxynet.io/fa/static-isp-residential-proxy) و [پروکسی دیتاسنتر](https://proxynet.io/fa/datacenter-proxy) پاسخ می‌دهند: در هر دو، نشانی فقط به شما اختصاص می‌یابد و تا وقتی آن را رها نکنید عوض نمی‌شود. قیمت پایه ماهانه برای نشانی ISP از ‎$ 1 و برای نشانی دیتاسنتر از ‎$ 0.70 است. برای کلاینت‌های API نشانی دیتاسنتر بیشتر وقت‌ها کافی است؛ اگر سرویس بلوک‌های نشانی مراکز داده را جداگانه محدود کند نشانی ISP انتخاب می‌شود.

## با پروکسی استاتیک چگونه یک نشانی خروجی واحد راه می‌اندازید؟

1. یک نشانی پروکسی استاتیک اختصاصی بگیرید.
2. با دستور زیر نشانی خروجی را اندازه بگیرید. نشانی‌ای که به سرویس اعلام می‌کنید همین پاسخ است؛ دستور را با چند ساعت فاصله تکرار کنید و ببینید نشانی همان می‌ماند:

   ```bash
   curl -x http://user:pass@pr.proxynet.io:8000 https://api.ipify.org
   ```

3. این نشانی را به ارائه‌دهنده API اعلام کنید (فیلد پنل یا درخواست پشتیبانی). فعال شدن تعریف بسته به سرویس ممکن است چند دقیقه یا چند ساعت طول بکشد؛ مدت آن را از مستندات سرویس بخوانید.
4. پروکسی را در کلاینت خود تعریف کنید. صفحه تنظیمات Postman را نوشته [تنظیم پروکسی در Postman](/fa/blog/postman-proxy)، خط فرمان را نوشته [استفاده از cURL با پروکسی](/fa/blog/curl-proxy) و کد برنامه را نوشته [استفاده از پروکسی در Node.js](/fa/blog/nodejs-proxy) گام‌به‌گام توضیح می‌دهد.
5. نشانی API را همیشه با `https://` فراخوانی کنید. اتصال TLS درون تونل مستقیم با سرور API برقرار می‌شود؛ کلید و داده شما به‌صورت آشکار به پروکسی نمی‌رسد.

## راستی‌آزمایی IP خروجی با کد

اگر نشانی یک بار درست دیده شود و بعد عوض شود، یک اندازه‌گیری تنها گمراه‌کننده است. اسکریپت زیر سه دور به دو سرویس پژواک جداگانه درخواست می‌فرستد، در هر اندازه‌گیری اتصال تازه‌ای باز می‌کند و همه نشانی‌هایی را که دیده با نشانی اعلام‌شده به سرویس مقایسه می‌کند. چون در صورت ناهمخوانی با کد `1` خارج می‌شود، می‌توان آن را به خط استقرار (CI) افزود. `203.0.113.10` یک نشانی نمونه است که برای مستندسازی کنار گذاشته شده است؛ نشانی خودتان را جای آن بنویسید.

```python
import sys
import time

import requests

PROXY_URL = "http://user:pass@pr.proxynet.io:8000"
EXPECTED_IP = "203.0.113.10"  # the address you reported to the API provider
ECHO_URLS = ["https://api.ipify.org", "https://checkip.amazonaws.com"]
ROUNDS = 3

def egress_ip(url):
    # Every measurement opens a new session: if an open tunnel is reused,
    # a changing egress address goes unnoticed.
    with requests.Session() as session:
        session.trust_env = False  # keep HTTP_PROXY / NO_PROXY from the shell out of it
        session.proxies = {"http": PROXY_URL, "https": PROXY_URL}
        response = session.get(url, timeout=15)
        response.raise_for_status()
        return response.text.strip()

def main():
    seen = set()
    for round_no in range(1, ROUNDS + 1):
        for url in ECHO_URLS:
            ip = egress_ip(url)
            seen.add(ip)
            print(f"round {round_no}  {url:<32} {ip}")
        time.sleep(2)

    if seen == {EXPECTED_IP}:
        print(f"OK: every request left from {EXPECTED_IP}")
        return 0
    print(f"MISMATCH: expected {EXPECTED_IP}, seen {sorted(seen)}")
    return 1

if __name__ == "__main__":
    sys.exit(main())
```

اسکریپت را از راه یک پروکسی آزمایشی محلی اجرا کردیم: هر یک از شش اندازه‌گیری تونل `CONNECT` جداگانه‌ای باز کرد و اسکریپت وقتی نشانی با مقدار مورد انتظار یکی بود با کد `0` و وقتی متفاوت بود با کد `1` خارج شد. وقتی رمز را عمداً اشتباه نوشتیم، Requests یک `ProxyError` حاوی `407` پرتاب کرد؛ خطای هویتی بی‌صدا به اتصال مستقیم برنمی‌گردد. اگر از پروکسی استفاده نمی‌کنید (خط یا سرور با IP ثابت) کافی است خط `session.proxies` را پاک کنید؛ این بار اسکریپت نشانی خروجی خود ماشین را بررسی می‌کند.

در Node.js هم همین بررسی بدون نصب بسته اضافه شدنی است. در نسخه‌های کنونی Node.js تابع داخلی `fetch` با تنظیم `NODE_USE_ENV_PROXY=1` متغیر `HTTPS_PROXY` را می‌خواند (جزئیات در نوشته Node.js ما آمده است):

```js
const EXPECTED_IP = process.env.EXPECTED_IP ?? "203.0.113.10";
const ECHO_URLS = ["https://api.ipify.org", "https://checkip.amazonaws.com"];

const seen = new Set();
for (const url of ECHO_URLS) {
  const response = await fetch(url, { signal: AbortSignal.timeout(15_000) });
  if (!response.ok) throw new Error(`${url}: HTTP ${response.status}`);
  const ip = (await response.text()).trim();
  seen.add(ip);
  console.log(url.padEnd(32), ip);
}

const ok = seen.size === 1 && seen.has(EXPECTED_IP);
console.log(ok ? `OK: ${EXPECTED_IP}` : `MISMATCH: expected ${EXPECTED_IP}, seen ${[...seen].join(", ")}`);
process.exitCode = ok ? 0 : 1;
```

```bash
NODE_USE_ENV_PROXY=1 HTTPS_PROXY="http://user:pass@pr.proxynet.io:8000" node check-egress-ip.mjs
```

## کاربردها

- **آزمایش یکپارچه‌سازی با بازارگاه:** محیط آزمایشی نشانی می‌خواهد و تیم پراکنده کار می‌کند. تیم از یک نشانی استاتیک بیرون می‌رود؛ هنگام رفتن به محیط عملیاتی قاعده سرویس برای آن محیط را دوباره بخوانید. سناریوهای دیگر حوزه فروش آنلاین در صفحه [پروکسی فروشگاه اینترنتی](/fa/e-commerce-proxy) آمده است.
- **آزمایش پاسخ‌های API وابسته به مکان:** برای دیدن اینکه یک نقطه پایانی از کشورهای گوناگون چگونه پاسخ می‌دهد از نشانی‌های ثابت با امکان انتخاب کشور استفاده می‌شود؛ چیدمان آن در صفحه [تست اپلیکیشن](/fa/app-testing) آمده است.
- **APIهای حمل، موجودی و تأمین‌کننده:** اگر انبار، حسابداری و تیم عملیاتی که از خانه کار می‌کند همگی به یک سرویس می‌روند، یا همه با VPN به شبکه دفتر وصل می‌شوند یا از یک نشانی استاتیک بیرون می‌روند.

## اگر IP درست است و هنوز خطا می‌گیرید

- **تعریف هنوز فعال نشده است.** اگر نشانی را امروز اعلام کرده‌اید، مدت پردازش سرویس را صبر کنید.
- **محیط اشتباه.** نشانی تعریف‌شده برای محیط آزمایشی در محیط عملیاتی کار نمی‌کند و کلید عملیاتی هم در محیط آزمایشی. دامنه و جفت کلید را با هم بررسی کنید.
- **از IPv6 بیرون می‌روید.** اگر `api64.ipify.org` نشانی IPv6 برمی‌گرداند و سرویس از IPv6 پشتیبانی می‌کند، یا نشانی IPv6 خود را هم اعلام کنید یا کلاینت را به IPv4 وادار کنید (`curl -4`).
- **سرآیند ناقص.** نبودن `User-Agent`، `Content-Type` یا سرآیند ویژه سرویس هم می‌تواند `403` برگرداند. درخواست نمونه مستندات را عیناً اجرا کنید و تفاوت را بیابید.
- **درخواست از ماشینی که فکر می‌کنید بیرون نمی‌رود.** ممکن است نشانی سرور نزد سرویس ثبت باشد و شما درخواست را از رایانه خودتان با Postman امتحان کنید؛ کار زمان‌بندی‌شده هم ممکن است روی سرور دیگری اجرا شود. اسکریپت را کنار همان فرایندی اجرا کنید که درخواست را می‌فرستد.
- **متغیر پروکسی در پوسته.** ابزاری که از ترمینالی با `HTTPS_PROXY` تعریف‌شده اجرا شود بی‌آنکه متوجه شوید از پروکسی بیرون می‌رود؛ برنامه‌ای که به‌صورت سرویس راه‌اندازی شده است اما متغیر پوسته را نمی‌بیند.

## راهنمای انتخاب

| وضعیت شما | پیشنهاد |
|---|---|
| یکپارچه‌سازی پرداخت، صورت‌حساب الکترونیکی، دفتر الکترونیکی، سلامت یا نهاد دولتی | IP ثابت روی خط خودتان یا سرور خودتان با نشانی رزروشده؛ از پروکسی استفاده نکنید |
| یکپارچه‌سازی پیوسته کار می‌کند (موجودی، سفارش، کار زمان‌بندی‌شده) | VPS یا سرور ابری با IP ثابت |
| چند سرور، کانتینر یا تابع serverless | ⁦NAT gateway⁩ ابری با نشانی رزروشده |
| کد روی یک رایانه در دفتر اجرا می‌شود | IP ثابت از ارائه‌دهنده اینترنت |
| محیط آزمایشی نشانی می‌خواهد و تیم از خانه کار می‌کند | پروکسی استاتیک اختصاصی شما |
| خط پشت CGNAT است، ارائه‌دهنده IP ثابت نمی‌دهد و داده حساس نیست | پروکسی استاتیک یا یک VPS کوچک |
| خطا `403` است اما نشانی درست است | سرآیندها، محیط و IPv6 را بررسی کنید |

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

### «مجوز IP لازم است» یعنی چه؟

یعنی سرویس نشانی‌ای را که درخواست شما از آن آمده با نشانی‌های ثبت‌شده حساب شما مقایسه کرده و همخوانی نیافته است. کلید API شما ممکن است درست باشد؛ مشکل در نشانی‌ای است که درخواست از آن بیرون رفته است. IP خروجی را روی ماشینی که درخواست را می‌فرستد اندازه بگیرید و با نشانی ثبت‌شده مقایسه کنید.

### آیا با IP پویا می‌توان با API یکپارچه شد؟

اگر سرویس نشانی نخواهد بله، هیچ مشکلی پیش نمی‌آید. اگر بخواهد، خط پویا راه‌حل ماندگار نیست: با هر بار عوض شدن نشانی باید دوباره به سرویس اعلام کنید و در این فاصله یکپارچه‌سازی می‌ایستد. با یکی از چهار گزینه یک نشانی خروجی ثابت بگیرید.

### آیا می‌توان بیش از یک نشانی IP در API تعریف کرد؟

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

### آیا با VPN می‌توان IP ثابت داشت؟

در برنامه‌های VPN مصرفی نه: نشانی‌ها میان کاربران زیادی مشترک است و ممکن است با هر اتصال عوض شود. سرور VPN خود شرکت شما اما کار می‌کند، چون نشانی خروجی آن سرور ثابت است و کارکنان دورکار از راه شبکه دفتر بیرون می‌روند.

### اگر از پروکسی استاتیک استفاده کنم، پروکسی کلید API مرا می‌بیند؟

اگر API را با `https://` فراخوانی کنید نه. پروکسی فقط نام و پورت سروری را می‌بیند که می‌خواهید به آن وصل شوید و سپس تونل رمزنگاری‌شده را عبور می‌دهد؛ کلید شما و پاسخ‌ها درون تونل‌اند. در APIای که با `http://` فراخوانی می‌شود همه‌چیز آشکار می‌رود؛ از چنین APIای چه با پروکسی و چه بدون آن استفاده نکنید.

### وقتی پروکسی را رها می‌کنم با ثبت IP در API چه کنم؟

همان روز بخواهید پاکش کنند. حتی اگر نشانی اختصاصی شما بوده باشد، پس از پایان سرویس ممکن است به مشتری دیگری داده شود و تا وقتی ثبت نزد سرویس بماند آن نشانی برای حساب شما مجاز است. همین قاعده برای نشانی‌های رزروشده سرورهایی که خاموش می‌کنید هم برقرار است.

## خلاصه

خطای مجوز IP خطای کد نیست، ناهمخوانی نشانی است: سرویس یک نشانی را می‌شناسد و درخواست شما از نشانی دیگری بیرون می‌رود. نخست IP خروجی را روی ماشینی که درخواست را می‌فرستد اندازه بگیرید، سپس نشانی را ثابت کنید. در یکپارچه‌سازی‌هایی که داده حساس جابه‌جا می‌کنند این نشانی باید IP ثابت خط خودتان، سرور خودتان یا ⁦NAT gateway⁩ در حساب ابری شما باشد؛ در پرداخت، سلامت و صورت‌حساب الکترونیکی شخص ثالثی را در میانه نگذارید. برای محیط‌های آزمایشی، تیم‌های پراکنده و دوره‌های گذار یک نشانی استاتیک اختصاصی کافی است؛ گزینه‌ها را در [خدمات پروکسی ما](/fa/proxy) می‌بینید.