دکمهٔ واحدی برای «تغییر IP» وجود ندارد، چون نشانی سرور به نوع شبکه و مکانش گره خورده است. کاری که میتوانید بکنید به نقطهٔ شروعتان بستگی دارد. چهار حالت تقریباً همهٔ درخواست‌هایی را که به ما می‌رسد پوشش می‌دهند و هیچ‌کدام به تیکت نیاز ندارند.
اگر مطمئن نیستید نوع شبکه‌تان چیست: در زبانهٔ شبکه سرور در داشبورد یا NAT نوشته شده یا IPv4 عمومی اختصاصی. تفاوت آن‌ها در شبکه و پورت‌ها توضیح داده شده است.
۱. سرور NAT ← IPv4 عمومی مخصوص خودش
رایج‌ترین حالت. سرور NAT نشانی IPv4 عمومی مخصوص خودش را ندارد: از راه یک پورت شخصی SSH (یا RDP) به آن وصل می‌شوید و بقیهٔ پورت‌های ورودی بسته‌اند. برای میزبانی وب‌سایت، سرور ایمیل یا هر چیزی که دیگران به آن وصل میشوند، به نشانی اختصاصی نیاز دارید.
نیازی به نصب دوباره نیست. در داشبورد سرور را باز کنید، به زبانهٔ صورتحساب بروید و از میان گزینه‌های ارتقا، تعرفه‌ای با IP اختصاصی هم‌اندازه یا بزرگتر انتخاب کنید. از راه API: اول گزینه‌ها و قیمت را ببینید، بعد ارتقا را با target_plan و confirm: true انجام دهید:
GET /services/{id}/upgrade-options
POST /services/{id}/upgrade-to-dedicated
چه اتفاقی می‌افتد:
- تفاوت دو قیمت ماهانه برای روزهای باقیماندهٔ دوره از موجودی‌تان کم میشود؛
- سرور با نشانی تازه راهاندازی دوباره میشود و دیسک و فایل‌هایتان همان‌طور می‌مانند؛
- SSH به پورت 22 روی IPv4 تازه میرود و هر پورتی که در فایروال باز کنید از بیرون در دسترس میشود؛
- از دورهٔ بعد قیمت تعرفهٔ تازه را میپردازید.
بعد از راهاندازی دوباره چه انتظاری داشته باشید. کلاینت SSH هشدار می‌دهد که کلید میزبان عوض شده، چون سرور برای نشانی تازه کلیدهای تازه می‌سازد. اگر رمز root را دستی عوض کرده بودید، آن را بررسی کنید؛ ممکن است به رمزی که در داشبورد نشان داده میشود برگشته باشد. و اگر تنظیمات شبکهٔ cloud-init را با پیکربندی خودتان جایگزین کردهاید، نشانی تازه خودبهخود اعمال نمی‌شود؛ از داشبورد کنسول وب را باز کنید و آن را آنجا تنظیم کنید.
این تغییر به یک نشانی آزاد در مکان سرورتان نیاز دارد. اگر در آن لحظه نباشد، ارتقا رد میشود و چیزی کم نمی‌شود.
۲. IPv4 دوم روی سرور دارای IP اختصاصی
اگر از قبل IPv4 اختصاصی دارید و یکی دیگر لازم است — سایت دوم با نشانی خودش، یا نشانی جدا برای ایمیل — آن را در صفحهٔ سرور در بخش IP اختصاصی اضافه کنید: $5 در ماه، کامل هنگام سفارش کم میشود و تاریخ تمدید خودش را دارد. از راه API:
POST /services/{id}/dedicated-ip
نشانی تازه پس از راهاندازی دوبارهٔ بعدی به‌صورت رابط شبکهٔ دوم ظاهر میشود. نشانی اصلی‌تان عوض نمی‌شود. اگر مکان سرور الان نشانی آزاد نداشته باشد، سفارش در صف می‌ماند و به محض آزاد شدن نشانی، خودکار اختصاص داده میشود.
اگر نشانی را بردارید یا سرور را لغو کنید، آن $5 بازگردانده نمی‌شود.
۳. IPv4 اختصاصی ← برگشت به NAT
در همان صفحه میتوانید سرور دارای IP اختصاصی را به تعرفهٔ NAT هم‌اندازه ببرید. IPv4 عمومی‌تان به مخزن ما برمی‌گردد، سرور با یک نشانی خصوصی و پورت شخصی SSH راهاندازی دوباره میشود و بقیهٔ پورت‌های ورودی بسته میشوند. به دیسک دست نمیخورد و صورتحساب به قیمت NAT میرود.
فقط وقتی این کار را بکنید که هیچ چیز به آن نشانی وابسته نباشد. پس از آزاد شدن، IPv4 ممکن است به کس دیگری برسد و نمی‌توانید درست همان نشانی را پس بگیرید.
۴. نشانی‌ای کاملاً متفاوت
بعضی‌ها فقط یک نشانی تازه می‌خواهند: پروژهٔ تازه، اعتبار پاک، کشوری دیگر. راهش سرور تازه است. سفارشش دهید، داده‌هایتان را منتقل کنید، DNS را به نشانی تازه بدهید و بعد سرور قدیمی را لغو کنید. هنگام سفارش از راه API یا MCP میتوانید کشور را با location: "de" یا "fi" انتخاب کنید.
این تنها راه بردن سرور به مکان دیگر هم هست: IPv4 به مکان خودش تعلق دارد.
کارهایی که نشانی را عوض نمی‌کنند
| کار | IPv4 اصلی |
|---|---|
| راهاندازی دوباره، خاموش و روشن کردن | می‌ماند |
| نصب دوبارهٔ سیستمعامل | می‌ماند |
| تعرفهٔ بزرگتر از همان نوع (NAT←NAT، IP←IP) | می‌ماند |
| تغییر hostname یا DNS معکوس | می‌ماند |
| NAT ← IP اختصاصی | IPv4 عمومی تازه |
| IP اختصاصی ← NAT | آزاد میشود |
| لغو سرور | آزاد میشود |
پیش از هر تغییری
- اگر دامنه‌ای به سرور اشاره میکند، چند ساعت زودتر TTL مربوط به DNS را پایین بیاورید تا تغییر سریع پخش شود.
- فهرست‌های مجاز را بررسی کنید. کلیدهای API صرافی‌ها، فایروال‌های شرکا و قواعد پایگاه داده که به نشانی قدیمی اعتماد دارند، به نشانی تازه نیاز دارند.
- اگر ایمیل می‌فرستید، DNS معکوس را روی نشانی تازه دوباره تنظیم کنید؛ برای هر نشانی جداست. شبکه و پورت‌ها را ببینید.
- نسخهٔ پشتیبان بگیرید. هیچ‌کدام از این مراحل به دیسک دست نمی‌زند، اما راهاندازی دوباره زمان خوبی برای داشتن نسخهٔ پشتیبان است. پشتیبان‌گیری مدیریت‌شده در نسخهٔ پشتیبان توضیح داده شده است.
اگر نشانی‌تان در فهرست سیاه است
ثبت معمولاً به ترافیکی برمی‌گردد که پیش از رسیدن نشانی به شما بوده، یا به سرور خودتان. در حالت دوم، عوض کردن نشانی چیزی را حل نمی‌کند. ثبت را بررسی کنید، علت را برطرف کنید و از فرم حذف فهرست استفاده کنید. اگر فکر میکنید ثبت اشتباه است، با نام فهرست و پیوندش تیکت باز کنید؛ هر مورد را بررسی میکنیم، اما نشانیها را به درخواست عوض نمیکنیم.
نظرات
هنوز نظری نیست. اولین نفر باشید.