[خانه](https://servhidden.com/fa) /
[راهنماهای میزبانی با حریم خصوصی](https://servhidden.com/fa/guides) /
چطور یک وب‌سایت را بدون قطعی به هاست آفشور مهاجرت دهیم






عملیات


# مهاجرت به هاست آفشور، بدون قطعی



تقریباً هر مهاجرت دردناکی یک شکست در ترتیب است، نه یک شکست فنی — TTLای که همان شب کاهش داده شده به‌جای دو روز زودتر، گواهی‌ای که بعد از تغییر DNS صادر شده به‌جای پیش از آن، کرون‌جابی که روی سروری که دیگر مرجع نیست فعال مانده است. این همان توالی‌ای است که پنجره قطعی را کاملاً حذف می‌کند، به‌علاوه بخشی که راهنماهای عمومی از قلم می‌اندازند: مهاجرت چه چیزی را برای همیشه درباره شما ثبت می‌کند، و در برابر آن چه کاری هنوز از دستتان برمی‌آید.


[بیشتر بخوانید](#guide-body)
[سؤالات متداول](#guide-faq)






## در این صفحه




- [راهنما](#guide-body)

- [سؤالات متداول](#guide-faq)

- [راهنماهای مرتبط](#guide-related)

- [صفحات پیشنهادی](#guide-cta)






بدون KYC
فقط ارز دیجیتال
بدون لاگ
DMCA نادیده گرفته می‌شود
دسترسی کامل Root
NVMe SSD





17 دقیقه مطالعه
به‌روزرسانی Aug 2026

در این صفحه

[01معنای واقعی «قطعی صفر»](#معنای-واقعی-قطعی-صفر)
[02TTL رکورد DNS را چند روز پیش از جابه‌جایی پایین بیاورید](#ttl-رکورد-dns-را-چند-روز-پیش-از-جابهجایی-پایین-بیاورید)
[03فهرست‌برداری از آنچه جابه‌جا می‌کنید، نه آنچه به‌خاطر دارید](#فهرستبرداری-از-آنچه-جابهجا-میکنید-نه-آنچه-بهخاطر-دارید)
[04اول سرور جدید را بسازید، و پیش از آنکه چیزی رویش باشد سخت‌سازی‌اش کنید](#اول-سرور-جدید-را-بسازید-و-پیش-از-آنکه-چیزی-رویش-باشد-سختسازی)
[05داده را دوبار کپی کنید: یک پاس کند، بعد یک پاس سریع](#داده-را-دوبار-کپی-کنید-یک-پاس-کند-بعد-یک-پاس-سریع)
[06پیش از آنکه DNS از وجودش خبردار شود، سرور جدید را تست کنید](#پیش-از-آنکه-dns-از-وجودش-خبردار-شود-سرور-جدید-را-تست-کنید)
[07جابه‌جایی نهایی، به‌ترتیب](#جابهجایی-نهایی-بهترتیب)
[08آنچه مهاجرت از خود به‌جا می‌گذارد](#آنچه-مهاجرت-از-خود-بهجا-میگذارد)
[09مسئله دامنه: با خودتان ببرید یا از نو شروع کنید؟](#مسئله-دامنه-با-خودتان-ببرید-یا-از-نو-شروع-کنید)
[10سرور قدیم را به‌درستی از رده خارج کنید](#سرور-قدیم-را-بهدرستی-از-رده-خارج-کنید)
[11کل توالی، در یک صفحه](#کل-توالی-در-یک-صفحه)
[FAQسؤالات رایج](#guide-faq)
[→صفحات پیشنهادی](#guide-cta)







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

هر دو ریسک یک درمان دارند، و آن درمان یک ابزار نیست. ترتیب است. مهاجرتی که با توالی درست اجرا شود هیچ پنجره‌ای ندارد که در آن سایت در دسترس نباشد، چون هر دو سرور هم‌زمان زنده‌اند و DNS آخرین چیزی است که جابه‌جا می‌شود. مهاجرتی که با توالی نادرست اجرا شود، هم‌زمان یک قطعی و یک رد به‌جا می‌گذارد. آنچه در ادامه می‌آید همان توالی است، نوشته‌شده برای کسی که به یک هاست آفشور و بدون KYC می‌رود، نه کسی که بین دو ارائه‌دهنده معروف جابه‌جا می‌شود — مکانیزم یکسان است، اما پاک‌سازی بعد از آن یکسان نیست.

## معنای واقعی «قطعی صفر»

این عبارت اغلب شل و بی‌دقت به‌کار می‌رود، و دقیقاً همین بی‌دقتی جایی است که آدم را گرفتار می‌کند. سرو کردن HTTP از دو دستگاه هم‌زمان کار ساده‌ای است. سازگار نگه‌داشتن *حالت (state)* وقتی دو دستگاه هم‌زمان سرو می‌کنند، بخش سخت ماجراست، و تنها بخشی است که تا به حال داده از دست داده. پس پیش از برنامه‌ریزی برای هر چیزی، مشخص کنید واقعاً کدام‌یک از این‌ها را دارید اجرا می‌کنید، چون همین جواب شکل کل آن شب را تعیین می‌کند.

| چه چیزی را جابه‌جا می‌کنید | بخشی که واقعاً گیر می‌کند | برنامه درست چیست |
| --- | --- | --- |
| سایت استاتیک، سایت بروشوری، خروجی تولیدشده | هیچ‌چیز. حالتی وجود ندارد که دو نیم شود | کپی کنید، تأیید کنید، جابه‌جا کنید. واقعاً قطعی صفر |
| یک CMS با پایگاه‌داده — WordPress، Ghost، یک انجمن | کامنت‌ها، ورودها و پست‌هایی که هم‌زمان روی دو پایگاه‌داده می‌نشینند | یک توقف فقط‌خواندنی که با **دقیقه** سنجیده می‌شود، در خلوت‌ترین ساعت شما |
| یک فروشگاه، یا هر چیزی که سفارش می‌گیرد | یک اسپلیت‌برین، سفارش‌های پرداخت‌شده را بی‌صدا از دست می‌دهد | پنجره تعمیر کوتاه را بپذیرید. از تطبیق دوباره حساب‌ها ارزان‌تر است |
| هر چیزی با کرون‌جاب یا ورکر پس‌زمینه | یک وظیفه یکسان روی هر دو سرور اجرا می‌شود — ایمیل دوبل، پرداخت دوبل | زمان‌بندی را روی سرور قدیم *پیش از* شروع سرور جدید غیرفعال کنید |
| ایمیل روی همان دامنه | رکوردهای MX طبق ساعت خودشان از کش‌ها منقضی می‌شوند، بی‌ربط به رکورد A شما | ایمیل را در شبی جدا جابه‌جا کنید، و MX قدیم را یک هفته فعال نگه دارید |

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

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

## TTL رکورد DNS را چند روز پیش از جابه‌جایی پایین بیاورید

این تنها گامی است که زمان انتظار دارد، و دقیقاً به همین دلیل هم اول آمده و هم همان گامی است که بیشتر افراد از آن رد می‌شوند. TTL شما — زمان ماندگاری — به هر ریزالوری در اینترنت می‌گوید تا چه مدت مجاز است رکورد شما را کش کند پیش از آنکه دوباره بپرسد. اگر رکورد A شما TTLای برابر با 86400 داشته باشد، ریزالوری که یک ساعت پیش آن را جست‌وجو کرده، تا بیست‌وسه ساعت دیگر همان IP قدیمی را تحویل می‌دهد، مهم نیست در ریجیستار چه چیزی را تغییر داده باشید.

نکته حیاتی این است که پایین‌آوردن TTL خودش تابع همان TTL قدیمی است. ریزالورها فقط وقتی از مقدار جدید و کوتاه‌تر باخبر می‌شوند که نسخه کش‌شده قدیمی منقضی شود. پس TTL را **دست‌کم یک دوره کامل TTL قدیمی پیش از جابه‌جایی نهایی** به 300 ثانیه کاهش دهید — با یک TTL یک‌روزه، یعنی این کار را 24 تا 48 ساعت زودتر انجام دهید. آن‌وقت کل اینترنت ظرف پنج دقیقه از تغییر، به رکورد جدید شما همگرا می‌شود، و جابه‌جایی نهایی دیگر یک رویداد پرتعلیق نیست.

چند روز بعد از جابه‌جایی، TTL را به مقداری معقول برگردانید. TTL سیصد ثانیه‌ای ابزار خوبی است اما تنظیم دائمی بدی است: حجم کوئری‌هایتان را چند برابر می‌کند و ارائه‌دهنده DNS شما را به یک نقطه شکست تک بسیار حساس‌تر تبدیل می‌کند.

## فهرست‌برداری از آنچه جابه‌جا می‌کنید، نه آنچه به‌خاطر دارید

هر مهاجرت شکست‌خورده‌ای همان کالبدشکافی را دارد: چیزی که هیچ‌کس فهرستش نکرده بود، کپی نشده. ریشه وب (web root) و پایگاه‌داده آن دو چیزی هستند که همه به‌خاطر می‌آورند؛ فهرست زیر بقیه ماجراست، و ارزشش را دارد که آن را واقعاً قدم‌به‌قدم طی کنید، نه از روی حافظه.

- **کارهای زمان‌بندی‌شده.** crontab -l برای هر کاربر، به‌علاوه تایمرهای systemd. هوک‌های تمدید و کارهای شبانه اینجا پنهان می‌شوند.

- **تعریف‌های سرویس.** واحدهای سفارشی systemd، vhostهای وب‌سرور، poolهای PHP-FPM، هر پیکربندی supervisor.

- **اسرار و محیط.** فایل‌های .env، کلیدهای API، پسوردهای پایگاه‌داده، سالت‌های اپلیکیشن — و توجه کنید که این‌ها باید چرخانده شوند، نه فقط کپی.

- **مواد TLS.** گواهی‌ها و، مهم‌تر از آن، حساب ACME و پیکربندی تمدید.

- **هویت ایمیل.** کلیدهای خصوصی DKIM، رکوردهای SPF و DMARC. عدم تطابق اینجا با سروصدا خراب نمی‌شود؛ فقط بی‌صدا ایمیل شما را به اسپم می‌فرستد.

- **رسانه‌های آپلودشده.** اغلب بیرون از ریشه وب، اغلب بزرگ‌ترین دارایی شما.

- **هر چیز بیرونی که به IP شما اعتماد می‌کند.** allowlistهای درگاه پرداخت، مقصدهای webhook، فایروال‌های پایگاه‌داده، APIهای شخص ثالث با محدودیت IP. این، رایج‌ترین دلیل شنیدن جمله «سایت کار می‌کند اما تسویه‌حساب خراب است» در ساعت 03:00 است.

- **فهرست پکیج‌ها.** dpkg --get-selections یا معادلش، تا دستگاه جدید همان اکستنشن‌ها و کتابخانه‌ها را داشته باشد، نه چیزی نزدیک به آن‌ها.

پیش از شروع کپی، فهرست را یادداشت کنید. این فهرست بعداً طرح تستتان هم هست — هر خط آن چیزی است که باید روی سرور جدید تأیید شود، پیش از آنکه DNS از وجودش خبردار شود.

## اول سرور جدید را بسازید، و پیش از آنکه چیزی رویش باشد سخت‌سازی‌اش کنید

مقصد را زود سفارش دهید و بگذارید یکی دو روز خالی روشن بماند. هم‌پوشانی هیچ هزینه‌ای ندارد — یک VPS آفشور کوچک چند دلار در ماه است — و ارزش زیادی دارد که ساخت آن را زیر فشار زمانی و با یک پایگاه‌داده منجمدشده که منتظر است، انجام ندهید.

محیط قدیم را عمداً مطابقت دهید: همان توزیع و همان نسخه اصلی، همان نسخه اصلی PHP یا Node یا Python، همان نسخه اصلی پایگاه‌داده. وسوسه مدرن‌سازی درست همان لحظه که آنجایید بسیار زیاد است و باید کاملاً در برابرش مقاومت کنید. اگر سایت بعد از جابه‌جایی نهایی خراب شود، می‌خواهید دقیقاً یک متغیر تغییر کرده باشد. استک را دو هفته بعد، در یک بعدازظهر معمولی، با امکان بازگشت، ارتقا دهید.

وقتی هنوز خالی است سخت‌سازی‌اش کنید. SSH فقط با کلید، فایروالی با سیاست پیش‌فرض رد، به‌روزرسانی‌های امنیتی خودکار — [چک‌لیست سخت‌سازی ساعت اول](https://servhidden.com/fa/guides/first-hour-vps-hardening-checklist) دقیقاً همین فهرست است، و روی دستگاهی که هیچ‌چیز رویش نیست، اعمال‌کردنش خیلی ساده‌تر است. اگر داده آن‌قدر حساس است که به‌خاطرش دارید حوزه قضایی عوض می‌کنید، همین هم لحظه درستی است برای تصمیم‌گیری درباره [رمزنگاری کامل دیسک](https://servhidden.com/fa/guides/full-disk-encryption-on-a-vps)، چون بعداً اضافه‌کردنش یعنی یک مهاجرت دیگر.

## داده را دوبار کپی کنید: یک پاس کند، بعد یک پاس سریع

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

برای فایل‌ها، rsync -aHAX --numeric-ids مجوزها، مالکیت، هاردلینک‌ها و ویژگی‌های گسترده (extended attributes) را حفظ می‌کند؛ فلگ --numeric-ids مهم است چون UIDها به‌ندرت بین دو دستگاه تازه‌ساخته با هم می‌خوانند. یک‌بار زود اجرایش کنید، بعد بلافاصله پیش از جابه‌جایی نهایی، با همان آرگومان‌ها دوباره اجرایش کنید — اجرای دوم فقط دلتا را منتقل می‌کند.

پایگاه‌داده‌ها به همان رفتار دومرحله‌ای نیاز دارند اما با ابزارهای متفاوت. یک mysqldump --single-transaction یا pg_dump یک اسنپ‌شات اولیه سازگار به شما می‌دهد که رویش بسازید و تست کنید. در لحظه جابه‌جایی نهایی، یا در طول توقف کوتاه نوشتن یک دامپ دوم بگیرید، یا — برای یک پایگاه‌داده بزرگ که حتی یک توقف کوتاه هم دردسرساز است — سرور جدید را روزها زودتر به‌عنوان یک ریپلیکا از سرور قدیم راه‌اندازی کنید، بگذارید به‌روز شود، بعد ترفیعش دهید. تکرارسازی توقف را به چند ثانیه تبدیل می‌کند. همچنین یک مهاجرت دوساعته را به یک پروژه دوروزه تبدیل می‌کند، پس فقط وقتی از آن استفاده کنید که اندازه داده واقعاً آن را ایجاب کند.

**پول کنید، نه پوش، و هرگز از مسیر لپ‌تاپ خودتان.** کپی را از سرور جدید آغاز کنید تا انتقال با سرعت دیتاسنتر و مستقیم بین دو هاست انجام شود. عبوردادن گیگابایت‌ها از اتصال خانگی‌تان کند است، و IP مسکونی شما را در لاگ‌های دسترسی هر دو دستگاه ثبت می‌کند — دقیقاً همان پیوندی که یک مهاجرت با انگیزه حریم خصوصی برای اجتنابش وجود دارد. اگر حتی باخبرشدن هاست قدیم از IP جدیدتان هم غیرقابل‌قبول است، اصلاً مستقیم کپی نکنید: در عوض سرور جدید را از [بکاپ رمزنگاری‌شده خارج از محل](https://servhidden.com/fa/guides/vps-backup-strategy) خودتان بازیابی کنید، و آن‌وقت این دو دستگاه هرگز با هم حرف نمی‌زنند.

## پیش از آنکه DNS از وجودش خبردار شود، سرور جدید را تست کنید

می‌توانید هاست‌نیم واقعی را از IP جدید سرو کنید بدون آنکه حتی یک رکورد عمومی را تغییر دهید، و باید هم همین کار را بکنید — همین چیزی است که جابه‌جایی نهایی را بی‌حادثه می‌کند. یک خط به فایل /etc/hosts محلی‌تان اضافه کنید که دامنه را به IP جدید اشاره دهد، یا از آن رد شوید و بگذارید curl همین کار را فقط برای یک درخواست انجام دهد:

curl -I --resolve example.com:443:203.0.113.10 https://example.com/

حالا فهرست را قدم‌به‌قدم طی کنید. صفحه اول و سه صفحه عمیق را بارگذاری کنید. وارد شوید. یک فرم را ارسال کنید. یک فایل آپلود کنید. بررسی کنید که اتصال پایگاه‌داده همان اتصال محلی جدید است، نه اینکه هنوز از روی اینترنت به هاست قدیم اشاره داشته باشد — اشتباهی که تا وقتی سرور قدیم را کنسل نکنید کاملاً درست کار می‌کند. کرون‌جاب‌ها را دستی اجرا کنید و خروجی‌شان را بخوانید. ریدایرکت‌ها را تأیید کنید و اینکه یک URL ناموجود هنوز 404 برمی‌گرداند، نه 200.

گواهی TLS را همین حالا صادر کنید، پیش از جابه‌جایی نهایی، نه بعد از آن. از چالش DNS-01 استفاده کنید، که کنترل دامنه را از طریق یک رکورد TXT ثابت می‌کند و به همین دلیل، حتی وقتی رکورد A هنوز به سرور قدیم اشاره دارد هم کار می‌کند. اگر برای اعتبارسنجی HTTP-01 بعد از تغییر DNS صبر کنید، هر بازدیدکننده زودهنگام در طول این شکاف یک هشدار گواهی می‌گیرد — یک قطعی خودخواسته درست در همان پنجره‌ای که می‌خواستید محافظتش کنید.

## جابه‌جایی نهایی، به‌ترتیب

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

- اگر کس دیگری به سایت وابسته است، پنجره کار را اعلام کنید، بعد سایت قدیم را به حالت فقط‌خواندنی یا تعمیر و نگهداری ببرید.

- **کرون و ورکرهای پس‌زمینه را روی هاست قدیم غیرفعال کنید.** این کار را پیش از راه‌انداختنشان روی سرور جدید بکنید، هرگز بعدش.

- پاس دلتای نهایی rsync و دامپ نهایی پایگاه‌داده را بگیرید، و آن را ایمپورت کنید.

- اپلیکیشن را روی سرور جدید بالا بیاورید و تست‌های اولیه خود را از طریق --resolve، روی داده نهایی، دوباره اجرا کنید.

- رکوردهای A و AAAA را به IP جدید تغییر دهید. با TTL سیصد ثانیه‌ای، کل اینترنت ظرف پنج دقیقه دنبال می‌کند.

- کرون و ورکرها را روی هاست جدید فعال کنید.

- هر دو لاگ دسترسی را کنار هم تماشا کنید. ترافیک از سرور قدیم خالی می‌شود و روی سرور جدید ظاهر می‌شود؛ وقتی سرور قدیم ساکت شد، جابه‌جایی نهایی کامل است.

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

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

## آنچه مهاجرت از خود به‌جا می‌گذارد

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

| چه چیزی این جابه‌جایی را ثبت می‌کند | چه کسی می‌تواند آن را بخواند | واقعاً چه کاری از دستتان برمی‌آید |
| --- | --- | --- |
| Passive DNS — رکوردهای A تاریخی | هرکسی، از طریق سرویس‌های تجاری تاریخچه | **هیچ‌کاری.** IP قدیمی برای همیشه به این نام مرتبط می‌ماند. طوری برنامه‌ریزی کنید که انگار عمومی است، چون هست |
| لاگ‌های Certificate Transparency | هرکسی، برای همیشه، قابل جست‌وجو بر اساس دامنه | هر گواهی‌ای که تا به‌حال صادر شده فهرست می‌شود — از جمله زیردامنه‌هایی که به‌نظر داخلی می‌رسیدند و فراموش‌شان کرده بودید. یک wildcard را به نام‌های توصیفی ترجیح دهید |
| رکوردهای حساب هاست قدیم | هاست قدیم، و هرکسی که بتواند مجبورشان کند | جزئیات کارت، ایمیل ثبت‌نام، IPهای ورود. یک مقصد بدون KYC از آینده محافظت می‌کند، نه از گذشته |
| تاریخچه WHOIS | آرشیوهای تجاری تاریخچه WHOIS | اگر دامنه حتی یک‌بار با جزئیات واقعی ثبت شده باشد، همان لحظه ضبط شده است. حریم خصوصی‌ای که بعداً اعمال شود آن را پس نمی‌گیرد |
| شناسه‌های آنالیتیکس و تبلیغات | فروشنده ابزار، و هرکسی که سورس صفحه شما را بخواند | حمل همان شناسه ردیابی، دو سایت را به‌شکلی قطعی به هم پیوند می‌دهد. یکی جدید صادر کنید، یا کلاً کنارش بگذارید |
| دامپ‌ها و بکاپ‌های جامانده روی دیسک قدیم | هرکسی که بعداً آن فضای ذخیره‌سازی به او تخصیص داده شود | پیش از کنسل‌کردن، حذف و رونویسی کنید. روی ذخیره‌سازی اشتراکی، فرض کنید حذف فقط یک اشاره است، نه یک تضمین |
| هدرهای Received: در ایمیل‌های ارسالی | هر گیرنده، برای همیشه | هیچ‌چیز عطف‌به‌ماسبق. فقط ایمیل‌هایی که بعد از جابه‌جایی می‌فرستید، مسیر جدید را حمل می‌کنند |
| اتصال‌های خودتان در طول کپی | ISP شما، و لاگ‌های دسترسی هر دو هاست | این یکی کاملاً دست خودتان است. هرگز از IPای که هویتتان را نشان می‌دهد، به هیچ‌کدام از دو دستگاه دست نزنید |

خلاصه صادقانه این است که یک مهاجرت نمی‌تواند گذشته را بازنویسی کند — فقط می‌تواند جلوی افزوده‌شدن به آن را بگیرد. این هنوز ارزش زیادی دارد، اما تصمیم را تغییر می‌دهد: اگر مدل تهدید شما ایجاب می‌کند که هیچ ناظری نتواند سایت جدید را به سایت قدیم پیوند بزند، جابه‌جایی همان دامنه به یک هاست جدید این هدف را برآورده نمی‌کند، و هیچ‌مقدار دقت در طول جابه‌جایی نهایی هم این را عوض نمی‌کند. آن حالت به یک نام جدید و یک شروع تمیز نیاز دارد، که در ادامه درباره‌اش صحبت می‌کنیم. اما اگر هدفتان این است که از امروز به بعد جلوی تولید رکوردهای شناسایی‌کننده را بگیرید، و مرکز ثقل حقوقی‌تان را به حوزه قضایی‌ای که خودتان انتخاب کرده‌اید ببرید، این جابه‌جایی دقیقاً همین کار را می‌کند. [راهنمای OpSec سرور](https://servhidden.com/fa/guides/server-opsec-staying-anonymous) ما، عادت‌هایی را پوشش می‌دهد که بعد از آن همه‌چیز را تمیز نگه می‌دارند.

## مسئله دامنه: با خودتان ببرید یا از نو شروع کنید؟

سایت و دامنه دو تصمیم مستقل‌اند، و قاطی‌کردنشان با هم رایج است. می‌توانید هاستینگ را همین امروز جابه‌جا کنید و ریجیستار را برای همیشه دست‌نخورده رها کنید؛ هیچ‌چیز در تغییر سرور شما را مجبور نمی‌کند به دامنه دست بزنید. اینکه آیا *باید* این کار را بکنید یا نه، کاملاً به این بستگی دارد که دامنه از قبل چه چیزی درباره شما می‌داند.

- **دامنه را نگه دارید، ریجیستار را عوض کنید.** وقتی دامنه ارزش دارد منطقی است — لینک‌ها، رتبه‌ها، نامی که مردم تایپ می‌کنند. این کار آینده رکورد WHOIS را درست می‌کند، نه تاریخچه‌اش را، و همه سیگنال‌های رتبه‌بندی را دست‌نخورده نگه می‌دارد. این جواب درست برای بیشتر سایت‌های تجاری است.

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

- **دامنه جدید، ریدایرکت به قدیمی.** رتبه‌ها را حفظ می‌کند، و دو نام را به‌شکلی عمومی و دائمی به هم پیوند می‌دهد. این را برای تداوم انتخاب کنید، هرگز برای حریم خصوصی — چون خودِ ریدایرکت همان پیوند است.

- **دامنه جدید، قطع تمیز.** تنها گزینه‌ای که واقعاً این پیوند را قطع می‌کند، و هر رتبه و لینک ورودی‌ای را که داشتید از شما می‌گیرد. از همان اول آن را به‌شکل خصوصی ثبت کنید، چون یک دامنه فقط به‌اندازه اولین ثبتش ناشناس است. راهنمای ما درباره [ثبت ناشناس دامنه با ارز دیجیتال](https://servhidden.com/fa/guides/anonymous-domain-registration-with-crypto) نحوه انجام درست این کار را پوشش می‌دهد.

عمداً انتخاب کنید، و پیش از جابه‌جایی نهایی این کار را بکنید، نه در حینش. تغییر نظر درباره دامنه بعد از جابه‌جایی DNS یعنی انجام بخش ظریف کار برای بار دوم.

## سرور قدیم را به‌درستی از رده خارج کنید

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

- مطمئن شوید هیچ‌چیز دیگر به IP قدیم اشاره نمی‌کند: آدرس‌های هاردکد‌شده در webhookهای شخص ثالث، allowlistها، مانیتورینگ، و هر رکورد DNSای که فراموش کرده بودید را بررسی کنید، مثل یک زیردامنه ولگرد mail یا cpanel.

- هر رازی که تا به‌حال روی آن دستگاه زندگی کرده را بچرخانید — پسوردهای پایگاه‌داده، کلیدهای API، سالت‌های اپلیکیشن، کلیدهای DKIM، کلیدهای SSH. آن‌ها را به جلو کپی نکنید.

- کلیدهای عمومی SSH خودتان و هر دسترسی پشتیبانی را از سرور قدیم حذف کنید.

- اپلیکیشن، دامپ‌ها و بکاپ‌ها را حذف کنید، بعد فضای آزاد را رونویسی کنید تا یک خواندن سرسری از ولوم بازیافتی چیزی به‌دست ندهد.

- فقط بعد از آن سرویس را خاتمه دهید، و هر روش پرداخت ذخیره‌شده را از حساب قدیم حذف کنید.

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

## کل توالی، در یک صفحه

استدلال‌ها را کنار بگذارید، یک مهاجرت هاست نه قدم است، که فقط دوتای آن‌ها فوریت دارند:

- **دو روز زودتر:** TTL رکورد DNS را به 300 ثانیه کاهش دهید.

- **دو روز زودتر:** سرور مقصد را سفارش دهید و سخت‌سازی کنید، نسخه‌به‌نسخه مطابق با استک قدیم.

- **روزها زودتر:** فهرست را بنویسید — کرون، اسرار، TLS، کلیدهای ایمیل، رسانه، allowlistهای IP، پکیج‌ها.

- **روزها زودتر:** اولین کپی کامل داده را، مستقیم بین دو هاست، انجام دهید.

- **پیش از پنجره:** گواهی را با DNS-01 صادر کنید و همه‌چیز را از طریق --resolve تست کنید.

- **پنجره (چند دقیقه):** نوشتن را متوقف کنید، کرون قدیم را غیرفعال کنید، کپی دلتا و دامپ نهایی را بگیرید، اپ جدید را بالا بیاورید.

- **پنجره (چند ثانیه):** رکورد A را تغییر دهید، بعد کرون را روی هاست جدید فعال کنید.

- **هفته بعد:** سرور قدیم را به‌عنوان مسیر بازگشت زنده نگه دارید، هر دو فایل لاگ را تماشا کنید، بعد TTL را دوباره بالا ببرید.

- **بعد از آن:** اسرار را بچرخانید، پاک‌سازی کنید، کنسل کنید — و به‌خاطر داشته باشید این جابه‌جایی چه چیزی را نتوانست پاک کند.

هیچ‌چیز در این فهرست سخت نیست. هر قدمی که درد دارد، قدمی است که بی‌ترتیب انجام شده — یک TTL که همان شب کاهش داده شده، گواهی‌ای که بعد از تغییر DNS صادر شده، یک کرون‌جاب که روی دستگاهی که دیگر مرجع نیست فعال مانده. توالی را درست انجام دهید و بخش جالب یک مهاجرت این می‌شود که کجا سرور را قرار دهید، نه خودِ جابه‌جایی. اگر هنوز این را مشخص نکرده‌اید، [راهنمای انتخاب حوزه قضایی](https://servhidden.com/fa/guides/choosing-an-offshore-jurisdiction) جای خوبی برای شروع است.





سؤالات متداول

## مهاجرت هاست — پرسش‌های رایج





### 01
واقعاً باید انتظار چقدر قطعی را داشته باشم؟



برای یک سایت استاتیک، اصلاً هیچ قطعی‌ای — هر دو سرور می‌توانند هم‌زمان همان محتوا را سرو کنند، پس تغییر DNS اصلاً دیده نمی‌شود. برای هر چیزی که پایگاه‌داده دارد، قطعی شما دقیقاً به اندازه طول توقف نوشتنتان است، که معمولاً اگر از قبل یک کپی کامل داده گرفته باشید، دو تا ده دقیقه است. عددی که اهمیت دارد این نیست که DNS چقدر سریع جابه‌جا می‌شود؛ این است که در طول پنجره چقدر کپی می‌کنید. تقریباً همه‌چیز را روزها زودتر کپی کنید تا پنجره به اندازه دلتا کوچک شود.





### 02
«پروپاگیشن DNS» چقدر طول می‌کشد؟



چیزی به‌اسم پروپاگیشن وجود ندارد — این کلمه چیزی را توصیف می‌کند که اصلاً اتفاق نمی‌افتد. ریزالورها فقط رکورد شما را به اندازه‌ای که TTLشان گفته کش می‌کنند، و وقتی منقضی شد دوباره می‌پرسند. اگر TTLای که در جریان بوده 86400 باشد، بعضی ریزالورها تا 24 ساعت دیگر همان IP قدیمی را سرو می‌کنند. TTL را دست‌کم یک دوره کامل TTL قدیمی پیش از جابه‌جایی نهایی به 300 ثانیه کاهش دهید تا کل اینترنت ظرف پنج دقیقه از تغییرتان پیروی کند.





### 03
آیا باید دامنه‌ام را هم جابه‌جا کنم؟



نه. ریجیستار و هاست کاملاً مستقل از هم‌اند، و جابه‌جایی سایت درحالی‌که دامنه دقیقاً همان‌جا که هست باقی می‌ماند، بی‌نقص کار می‌کند. اینکه آیا باید جابه‌جایش کنید یا نه، به دلیل مهاجرتتان بستگی دارد: اگر به‌خاطر حوزه قضایی، قیمت یا موضع DMCA بوده، دامنه را دست‌نخورده رها کنید. اگر به‌خاطر گمنامی بوده، توجه کنید که دامنه تاریخچه جداگانه خودش را حمل می‌کند — آرشیوهای WHOIS هر جزئیاتی که دامنه اولین‌بار با آن ثبت شده را نگه می‌دارند، و تغییر هاست دستی به آن نمی‌رساند.





### 04
آیا می‌توانم مهاجرت کنم بدون آنکه هاست قدیم بفهمد کجا رفته‌ام؟



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





### 05
آیا باید هم‌زمان سیستم‌عامل یا استک را هم ارتقا دهم؟



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





### 06
آیا مهاجرت به رتبه‌های جست‌وجویم آسیب می‌زند؟



نه به‌شکل معناداری، به‌شرطی که دامنه، URLها و محتوا همان بمانند — گوگل URLها را ایندکس می‌کند، نه آدرس‌های IP را، و تغییر هاست به‌تنهایی یک سیگنال رتبه‌بندی نیست. ساختار URL را عیناً یکسان نگه دارید، همان کدهای وضعیت را برگردانید، و جابه‌جایی را با یک بازطراحی یا تغییر ساختار URL ترکیب نکنید. اگر در عوض دارید به یک دامنه جدید می‌روید، حتی با ریدایرکت‌های 301 درست هم انتظار یک افت موقت را داشته باشید، و بدانید که همان ریدایرکت‌ها هم دو نام را به‌شکل عمومی به هم وصل می‌کنند.





### 07
آیا باید گواهی‌های TLS را دوباره صادر کنم؟



بله — سرور جدید به گواهی و کلید خصوصی خودش نیاز دارد، و کپی‌کردن کلید قدیمی به جلو، حتی وقتی از نظر فنی کار می‌کند، عادت بدی است. آن را پیش از جابه‌جایی نهایی با یک چالش DNS-01 صادر کنید، که از طریق یک رکورد TXT اعتبارسنجی می‌شود و به همین دلیل، حتی وقتی رکورد A هنوز به هاست قدیم اشاره دارد هم موفق می‌شود. صبرکردن برای HTTP-01 بعد از تغییر DNS، تضمین می‌کند یک بازه از هشدارهای گواهی درست در همان پنجره‌ای که می‌خواستید محافظتش کنید، پیش بیاید.





### 08
چه زمانی کنسل‌کردن سرور قدیم امن است؟



بعد از یکی دو هفته لاگ‌های ساکت روی دستگاه قدیم و لاگ‌های تمیز روی دستگاه جدید — این تأخیر همان مسیر بازگشت شماست، و چند دلار هزینه دارد. پیش از کنسل‌کردن، بررسی کنید هیچ‌چیز بیرونی دیگر به IP قدیم اشاره نکند، هر رازی که تا به‌حال روی آن زندگی کرده را بچرخانید، بعد داده‌تان را حذف کنید و فضای آزاد را رونویسی کنید. کنسل‌کردن را برای آخر بگذارید. اول زدن دکمه خاتمه، پایگاه‌داده شما را روی دیسکی می‌گذارد که دیگر کنترلش دست شما نیست.




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

## ادامه مطلب


[### چطور در سال 2026 یک حوزه قضایی آفشور برای میزبانی انتخاب کنید

خرید


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


سؤالات متداول 6‌گانه](https://servhidden.com/fa/guides/choosing-an-offshore-jurisdiction)
[### VPS در مقابل سرور اختصاصی برای بارهای کاری حساس به حریم خصوصی

خرید


چه زمانی VPS کافی است، چه زمانی اشتراک در منابع یک خطر امنیتی است، و چه زمانی bare-metal تنها پاسخ صادقانه است. ایزولاسیون سخت‌افزاری، ریسک هایپروایزر، و هزینه در برابر مدل تهدید.


سؤالات متداول 6‌گانه](https://servhidden.com/fa/guides/vps-vs-dedicated-for-privacy)
[### VPN خودمیزبان روی VPS بدون KYC: WireGuard در مقابل OpenVPN

عملیات


چرا VPN خودمیزبان از ارائه‌دهندگان تجاری بهتر است، و WireGuard و OpenVPN واقعاً از نظر حریم خصوصی، عملکرد و ریسک عملیاتی در سال 2026 چگونه مقایسه می‌شوند.


سؤالات متداول 6‌گانه](https://servhidden.com/fa/guides/self-hosted-vpn-wireguard-vs-openvpn)
[### RTX 4090 در مقابل H100 SXM5 برای استنتاج هوش مصنوعی (و جایگاه RTX 5090)

خرید


راهنمای خرید: کدام GPU از NVIDIA برای بارهای کاری LLM سلف‌هاست، تصویر، ویدیو، صدا و تنظیم دقیق در ۲۰۲۶. RTX 4090 در مقابل RTX 5090 در مقابل H100 SXM5 در مقابل دو H100 — VRAM، توان عملیاتی، $/توکن، و برتری هر کدام.


سؤالات متداول 6‌گانه](https://servhidden.com/fa/guides/rtx-4090-vs-h100-for-ai-inference)
[### RDP ویندوز آفشور برای معاملات Forex با MT4 / MT5 / cTrader

عملیات


راهنمای کامل: چرا به Windows RDP برای معاملات Forex نیاز دارید، چگونه یک حوزه قضایی آفشور با تأخیر کم انتخاب کنید، راه‌اندازی MT4 / MT5 / cTrader / Expert Advisor، تأخیر تا سرورهای کارگزار، و مسیر پرداخت بدون KYC.


سؤالات متداول 6‌گانه](https://servhidden.com/fa/guides/offshore-windows-rdp-for-forex-trading)
[### میزبانی DMCA-Ignored توضیح داده شد: معنای واقعی آن در 2026

خرید


میزبانی «DMCA ignored» واقعاً چه چیزی به شما می‌دهد، کدام حوزه‌های قضایی واقعاً از آن پشتیبانی می‌کنند، چه بارهای کاری به آن نیاز دارند، و دام‌های حق مؤلفی که این اصطلاح پوشش نمی‌دهد.


سؤالات متداول 6‌گانه](https://servhidden.com/fa/guides/dmca-ignored-hosting-explained)
[### ثبت دامنه ناشناس با ارز دیجیتال: حریم خصوصی WHOIS در 2026

حریم خصوصی


راهنمای عملی 2026 برای ثبت دامنه بدون افشای هویت: رژیم‌های WHOIS بر اساس TLD، انتخاب رجیسترار، گزینه‌های پرداخت با ارز دیجیتال، و اشتباهات عملیاتی که هویت شما را لو می‌دهند.


سؤالات متداول 6‌گانه](https://servhidden.com/fa/guides/anonymous-domain-registration-with-crypto)
[### پرداخت‌های کریپتو برای هاستینگ: Monero در مقابل Bitcoin در مقابل USDT

حریم خصوصی


چگونه انتخاب ارز پرداخت تأثیر می‌گذارد که هاست شما چه چیزی درباره‌تان می‌داند. حریم خصوصی، کارمزدها، قطعیت تراکنش و میزان افشاگری در تحلیل زنجیره برای XMR، BTC و USDT — با یک توصیه صریح.


سؤالات متداول 6‌گانه](https://servhidden.com/fa/guides/crypto-payments-monero-vs-bitcoin-vs-usdt)
[### آیا هاستینگ آفشور واقعاً ناشناس است؟ یک پاسخ صادقانه

حریم خصوصی


هاستینگ آفشور و بدون KYC هویتی را که یک هاست معمولی جمع‌آوری می‌کند حذف می‌کند — اما «ناشناس‌بودن» به پرداخت، لاگ‌گیری ارائه‌دهنده و امنیت عملیاتی (opsec) خودتان بستگی دارد. در ادامه می‌بینید واقعاً چه چیزی قابل ردیابی است.


سؤالات متداول 6‌گانه](https://servhidden.com/fa/guides/is-offshore-hosting-truly-anonymous)
[### ساعت اول سخت‌سازی VPS: یک چک‌لیست

عملیات


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


سؤالات متداول 6‌گانه](https://servhidden.com/fa/guides/first-hour-vps-hardening-checklist)
[### What Is No-KYC Hosting? Definition, Legality & How It Works

حریم خصوصی


No-KYC hosting lets you rent a server with zero identity verification — no name, no email, no ID. Here is exactly what it means, how it works technically, whether it is legal, and how to pick a genuine provider.


سؤالات متداول 6‌گانه](https://servhidden.com/fa/guides/what-is-no-kyc-hosting)
[### Is Offshore Hosting Legal? The Honest 2026 Answer

خرید


Offshore hosting is legal — for you and for the provider. Here is what the term really means, where the legal line actually sits, the myths worth dropping, and how to use it responsibly.


سؤالات متداول 6‌گانه](https://servhidden.com/fa/guides/is-offshore-hosting-legal)
[### How to Pay for Hosting with Monero (XMR) — Step by Step

حریم خصوصی


A step-by-step guide to paying for a VPS or dedicated server with Monero (XMR): why XMR is the most private option, how to get it, and how the checkout works — from invoice to a running server in minutes.


سؤالات متداول 6‌گانه](https://servhidden.com/fa/guides/how-to-pay-for-hosting-with-monero)
[### How to Host a Website Anonymously — A Practical 2026 Guide

حریم خصوصی


A practical, layered guide to hosting a website with no identity attached: the account, the payment, the domain, the jurisdiction, your connection and the content — each layer explained.


سؤالات متداول 6‌گانه](https://servhidden.com/fa/guides/how-to-host-a-website-anonymously)
[### How to Set Up a WireGuard VPN on a VPS — Step-by-Step Guide

عملیات


Build your own private VPN on a VPS with WireGuard: why a self-hosted VPN beats a commercial one, the full setup from install to a connected client, and how to harden it.


سؤالات متداول 6‌گانه](https://servhidden.com/fa/guides/how-to-set-up-wireguard-vpn-on-a-vps)
[### How to Self-Host an LLM on a GPU Server — 2026 Guide

عملیات


Run your own large language model on a rented GPU server: why self-hosting beats an API, which GPU and model to choose, the setup with Ollama or vLLM, and what it costs.


سؤالات متداول 6‌گانه](https://servhidden.com/fa/guides/self-host-an-llm-on-a-gpu-server)
[### Bulletproof Hosting vs Offshore Hosting — What Is the Difference?

خرید


Bulletproof hosting and offshore hosting are constantly confused — and they are not the same thing. Here is the real difference, why it matters, and which one you actually want.


سؤالات متداول 6‌گانه](https://servhidden.com/fa/guides/bulletproof-vs-offshore-hosting)
[### How to Buy a VPS with Bitcoin — Step-by-Step (2026)

خرید


A beginner-friendly walkthrough of buying a VPS with Bitcoin: getting BTC, choosing a plan, paying the invoice, and what you get — a running server with no card and no name attached.


سؤالات متداول 6‌گانه](https://servhidden.com/fa/guides/how-to-buy-a-vps-with-bitcoin)
[### Best Countries for DMCA-Ignored Hosting in 2026

خرید


Where to host when you want servers beyond the easy reach of US-style takedowns: the jurisdictions that work, what DMCA-ignored really means, and how to choose.


سؤالات متداول 6‌گانه](https://servhidden.com/fa/guides/best-countries-for-dmca-ignored-hosting)
[### How to Host a Tor Hidden Service (.onion Site) — 2026 Guide

عملیات


Set up a Tor onion service on a VPS: what a hidden service is, why it is the strongest form of anonymous hosting, the full setup, and how to keep it actually anonymous.


سؤالات متداول 6‌گانه](https://servhidden.com/fa/guides/how-to-host-a-tor-hidden-service)
[### Offshore Mail Server Setup — Self-Host Private Email in 2026

عملیات


Run your own private email server on an offshore VPS: why self-host email, what you need, the realistic setup with an all-in-one mail stack, and how to get deliverability right.


سؤالات متداول 6‌گانه](https://servhidden.com/fa/guides/offshore-mail-server-setup)
[### Crypto Node Hosting Guide — Run a Blockchain Node on a VPS

عملیات


How to host a blockchain node on a server: why run your own node, sizing the server for Bitcoin, Ethereum, Monero and more, the setup, and keeping it private.


سؤالات متداول 6‌گانه](https://servhidden.com/fa/guides/crypto-node-hosting-guide)
[### GPU Hosting for Stable Diffusion — Run Your Own Image Server

عملیات


Run Stable Diffusion on your own GPU server: why self-host image generation, which GPU to pick, the setup with a web UI, and what it costs versus a hosted service.


سؤالات متداول 6‌گانه](https://servhidden.com/fa/guides/gpu-hosting-for-stable-diffusion)
[### Server OpSec — Staying Anonymous When You Run a Server

حریم خصوصی


Operational security for anyone running an anonymous server: the mistakes that deanonymise people, the habits that prevent them, and how to keep identities truly separate.


سؤالات متداول 6‌گانه](https://servhidden.com/fa/guides/server-opsec-staying-anonymous)
[### Seedbox Setup Guide — Build Your Own Private Seedbox in 2026

عملیات


How to build your own seedbox on a server: what a seedbox is, sizing it, installing a torrent client with a web UI, and keeping it private and secure.


سؤالات متداول 6‌گانه](https://servhidden.com/fa/guides/seedbox-setup-guide)
[### How to Bypass DPI Censorship with Your Own VPS (2026 Guide)

حریم خصوصی


Your VPN stopped working? How to bypass DPI censorship with your own VPS: what deep packet inspection actually detects, which of the five 2026 protocols beats which block, and a full VLESS+REALITY walkthrough.


سؤالات متداول 6‌گانه](https://servhidden.com/fa/guides/bypass-dpi-censorship-with-your-own-vps)
[### رمزگذاری کامل دیسک روی VPS: راه‌اندازی LUKS و محافظت واقعی آن

عملیات


چگونه یک VPS را با LUKS رمزگذاری کنید: حجم‌های داده‌ی رمزشده، رمزگذاری کامل روت با بازکردن قفل از راه دور روی SSH، تنظیماتی که روی سرور کوچک اهمیت دارند، و توضیحی صادقانه از آنچه رمزگذاری دیسک واقعاً متوقف می‌کند.


سؤالات متداول 8‌گانه](https://servhidden.com/fa/guides/full-disk-encryption-on-a-vps)
[### پنهان‌کردن IP سرور مبدأ: CDN، پراکسی معکوس و آنچه هنوز لو می‌رود

حریم خصوصی


اینکه آیا باید CDN را جلوی یک سرور آفشور گذاشت: چه چیزی را پنهان می‌کند، چه دفتر شکایاتی به ارث می‌رسد، شش راهی که IP مبدأ باز هم لو می‌رود، و چگونه IP خودتان را بررسی کنید.


سؤالات متداول 8‌گانه](https://servhidden.com/fa/guides/hiding-your-origin-server-ip)
[### استراتژی بکاپ VPS: رمزنگاری‌شده، آفشور و واقعاً قابل بازیابی

عملیات


هاست شما بکاپی نگه نمی‌دارد. چه چیزی واقعاً سرورها را نابود می‌کند، چرا بکاپ پوش با سرور از بین می‌رود، مقایسه restic و Borg، کلیدهای فراموش‌شده، و روش تست بازیابی.


سؤالات متداول 8‌گانه](https://servhidden.com/fa/guides/vps-backup-strategy)
[### راه‌اندازی سرور Matrix: فدراسیون، متادیتا و آنچه رمزگذاری پنهان نمی‌کند

عملیات


هوم‌سرور Matrix شخصی واقعاً چه می‌دهد: Synapse در برابر Conduit، server_name‌ای که هرگز تغییر نمی‌کند، رسانه‌ای که دیسک را پر می‌کند، و آنچه فدراسیون هنوز آشکار می‌کند.


سؤالات متداول 8‌گانه](https://servhidden.com/fa/guides/self-host-a-matrix-server)
[### How to Self-Host a Crypto Payment Gateway with BTCPay Server

عملیات


Run your own non-custodial checkout on an offshore VPS: BTCPay Server, a pruned Bitcoin node, Lightning and Monero — how to size the disk, why the private keys must never touch the machine, and where KYC quietly reappears at the cash-out.


سؤالات متداول 8‌گانه](https://servhidden.com/fa/guides/self-host-a-crypto-payment-gateway)




## به مهاجرتتان جایی برای فرود بدهید



سرورهای KVM آفشور در هفت حوزه قضایی از $7.50/mo، با روت کامل، ذخیره‌سازی NVMe و پهنای باند نامحدود، که به‌محض تأیید پرداخت ارز دیجیتال، ظرف کمتر از پنج دقیقه دیپلوی می‌شوند. مقصد را زود راه بیندازید، با سرعت خودتان کپی کنید، و هروقت آماده بود جابه‌جایی نهایی را انجام دهید.


[مشاهده پلن‌های VPS](https://servhidden.com/fa/vps)
[Offshore Hosting](https://servhidden.com/fa/offshore-hosting)
[همه مناطق](https://servhidden.com/fa/locations)


## Structured data (JSON-LD)

```json
{
    "@context": "https://schema.org",
    "@type": "Organization",
    "@id": "https://servhidden.com/#organization",
    "name": "ServHidden",
    "url": "https://servhidden.com",
    "description": "VPS آفشور و سرورهای اختصاصی در 7 حوزه قضایی آفشور. بدون KYC، بدون لاگ، فقط ارز دیجیتال. حریم خصوصی از طریق معماری.",
    "logo": {
        "@type": "ImageObject",
        "url": "https://servhidden.com/ServHidden.webp",
        "width": 512,
        "height": 512
    },
    "foundingDate": "2025",
    "areaServed": [
        {
            "@type": "Country",
            "name": "Iceland"
        },
        {
            "@type": "Country",
            "name": "Panama"
        },
        {
            "@type": "Country",
            "name": "Moldova"
        },
        {
            "@type": "Country",
            "name": "Romania"
        },
        {
            "@type": "Country",
            "name": "Switzerland"
        },
        {
            "@type": "Country",
            "name": "Netherlands"
        },
        {
            "@type": "Country",
            "name": "Russia"
        }
    ],
    "knowsAbout": [
        "Offshore hosting",
        "Offshore VPS",
        "Bare-metal dedicated servers",
        "DMCA-ignored hosting",
        "No KYC hosting",
        "Cryptocurrency payments",
        "Privacy engineering",
        "Token-based authentication",
        "Anonymous domain name registration",
        "No-KYC domain registrar",
        "WHOIS privacy",
        "Cheap .com domains",
        "Crypto-paid domain names",
        "NVIDIA GPU compute",
        "Windows RDP hosting",
        "Agentic commerce"
    ],
    "contactPoint": {
        "@type": "ContactPoint",
        "contactType": "customer support",
        "url": "https://servhidden.com/contact",
        "availableLanguage": [
            "en",
            "ru",
            "zh",
            "es",
            "fr",
            "de",
            "pt",
            "ar",
            "ja",
            "ko",
            "hi",
            "id",
            "it",
            "tr",
            "fa",
            "vi"
        ]
    },
    "sameAs": [
        "https://servhidden.com/canary",
        "https://servhidden.com/press"
    ]
}
```

```json
{
    "@context": "https://schema.org",
    "@type": "WebSite",
    "@id": "https://servhidden.com/#website",
    "url": "https://servhidden.com",
    "name": "ServHidden",
    "publisher": {
        "@id": "https://servhidden.com/#organization"
    },
    "inLanguage": [
        "en",
        "ru",
        "zh",
        "es",
        "fr",
        "de",
        "pt",
        "ar",
        "ja",
        "ko",
        "hi",
        "id",
        "it",
        "tr",
        "fa",
        "vi"
    ]
}
```

```json
{
    "@context": "https://schema.org",
    "@type": "Article",
    "headline": "چطور یک وب‌سایت را بدون قطعی به هاست آفشور مهاجرت دهیم",
    "description": "ترتیبی که مهاجرت هاست را کسل‌کننده می‌کند: کاهش TTL رکورد DNS چند روز پیش از موعد، اجرای هم‌زمان هر دو سرور، توقف نوشتن برای چند دقیقه به‌جای چند ساعت — و پاک‌سازی ردی که این جابه‌جایی در Passive DNS، لاگ‌های Certificate Transparency و WHOIS از خود به‌جا می‌گذارد.",
    "image": "https://servhidden.com/assets/img/guides/migrate-website-to-offshore-hosting.webp?v=1787969426",
    "author": {
        "@type": "Organization",
        "@id": "https://servhidden.com/#editorial",
        "name": "ServHidden Editorial",
        "url": "https://servhidden.com/about",
        "description": "Operator-side editorial team writing about offshore hosting jurisdictions, offshore server architecture, self-hosted privacy stacks and crypto payments.",
        "knowsAbout": [
            "Offshore hosting jurisdictions",
            "Data retention law",
            "MLAT and judicial cooperation",
            "WireGuard and OpenVPN deployment",
            "Tor relay operation",
            "Monero and Bitcoin payment privacy",
            "KVM virtualization and bare-metal hosting",
            "DMCA-ignored hosting"
        ],
        "parentOrganization": {
            "@id": "https://servhidden.com/#organization"
        }
    },
    "publisher": {
        "@id": "https://servhidden.com/#organization"
    },
    "datePublished": "2026-08-29T00:00:00+00:00",
    "dateModified": "2026-08-29T00:00:00+00:00",
    "mainEntityOfPage": "https://servhidden.com/guides/migrate-website-to-offshore-hosting",
    "inLanguage": "fa",
    "keywords": "مهاجرت وب‌سایت به هاست آفشور, تغییر هاست بدون قطعی, مهاجرت VPS به هاست جدید, کاهش TTL دامنه پیش از مهاجرت, چک‌لیست مهاجرت سرور, مهاجرت سایت به هاست بدون KYC, جابه‌جایی سرور با rsync",
    "articleSection": "عملیات",
    "wordCount": 3257
}
```

```json
{
    "@context": "https://schema.org",
    "@type": "FAQPage",
    "mainEntity": [
        {
            "@type": "Question",
            "name": "واقعاً باید انتظار چقدر قطعی را داشته باشم؟",
            "acceptedAnswer": {
                "@type": "Answer",
                "text": "برای یک سایت استاتیک، اصلاً هیچ قطعی‌ای — هر دو سرور می‌توانند هم‌زمان همان محتوا را سرو کنند، پس تغییر DNS اصلاً دیده نمی‌شود. برای هر چیزی که پایگاه‌داده دارد، قطعی شما دقیقاً به اندازه طول توقف نوشتنتان است، که معمولاً اگر از قبل یک کپی کامل داده گرفته باشید، دو تا ده دقیقه است. عددی که اهمیت دارد این نیست که DNS چقدر سریع جابه‌جا می‌شود؛ این است که در طول پنجره چقدر کپی می‌کنید. تقریباً همه‌چیز را روزها زودتر کپی کنید تا پنجره به اندازه دلتا کوچک شود."
            }
        },
        {
            "@type": "Question",
            "name": "«پروپاگیشن DNS» چقدر طول می‌کشد؟",
            "acceptedAnswer": {
                "@type": "Answer",
                "text": "چیزی به‌اسم پروپاگیشن وجود ندارد — این کلمه چیزی را توصیف می‌کند که اصلاً اتفاق نمی‌افتد. ریزالورها فقط رکورد شما را به اندازه‌ای که TTLشان گفته کش می‌کنند، و وقتی منقضی شد دوباره می‌پرسند. اگر TTLای که در جریان بوده 86400 باشد، بعضی ریزالورها تا 24 ساعت دیگر همان IP قدیمی را سرو می‌کنند. TTL را دست‌کم یک دوره کامل TTL قدیمی پیش از جابه‌جایی نهایی به 300 ثانیه کاهش دهید تا کل اینترنت ظرف پنج دقیقه از تغییرتان پیروی کند."
            }
        },
        {
            "@type": "Question",
            "name": "آیا باید دامنه‌ام را هم جابه‌جا کنم؟",
            "acceptedAnswer": {
                "@type": "Answer",
                "text": "نه. ریجیستار و هاست کاملاً مستقل از هم‌اند، و جابه‌جایی سایت درحالی‌که دامنه دقیقاً همان‌جا که هست باقی می‌ماند، بی‌نقص کار می‌کند. اینکه آیا باید جابه‌جایش کنید یا نه، به دلیل مهاجرتتان بستگی دارد: اگر به‌خاطر حوزه قضایی، قیمت یا موضع DMCA بوده، دامنه را دست‌نخورده رها کنید. اگر به‌خاطر گمنامی بوده، توجه کنید که دامنه تاریخچه جداگانه خودش را حمل می‌کند — آرشیوهای WHOIS هر جزئیاتی که دامنه اولین‌بار با آن ثبت شده را نگه می‌دارند، و تغییر هاست دستی به آن نمی‌رساند."
            }
        },
        {
            "@type": "Question",
            "name": "آیا می‌توانم مهاجرت کنم بدون آنکه هاست قدیم بفهمد کجا رفته‌ام؟",
            "acceptedAnswer": {
                "@type": "Answer",
                "text": "نه اگر مستقیم بین دو دستگاه کپی کنید — یک سر به سر دیگر وصل می‌شود، و هر دو دسته لاگ دسترسی آن را ثبت می‌کنند. اگر این پیوند واقعاً برای مدل تهدید شما اهمیت دارد، اصلاً بین دو هاست مستقیم کپی نکنید: سرور جدید را از بکاپ رمزنگاری‌شده و خارج از محل خودتان بازیابی کنید، تا دو ارائه‌دهنده هرگز حتی یک پکت هم رد و بدل نکنند. در هر صورت، هرگز انتقال را از اتصالی که هویتتان را نشان می‌دهد آغاز نکنید، و مقصد را از هر تیکت پشتیبانی‌ای که نزد ارائه‌دهنده قدیم باز می‌کنید، بیرون نگه دارید."
            }
        },
        {
            "@type": "Question",
            "name": "آیا باید هم‌زمان سیستم‌عامل یا استک را هم ارتقا دهم؟",
            "acceptedAnswer": {
                "@type": "Answer",
                "text": "نه، و این رایج‌ترین شکست خودخواسته در مهاجرت است. فقط یک چیز را تغییر دهید. اگر سایت بعد از جابه‌جایی نهایی بدرفتاری کند، می‌خواهید یک توضیح کاندیدای واحد داشته باشید، نه انتخابی بین دستگاه جدید، نسخه جدید PHP و نسخه اصلی جدید پایگاه‌داده. محیط قدیم را نسخه‌به‌نسخه مطابقت دهید، جابه‌جایی را کامل کنید، یک هفته لاگ‌های تمیز را تأیید کنید، بعد جداگانه و با امکان بازگشت ارتقا دهید."
            }
        },
        {
            "@type": "Question",
            "name": "آیا مهاجرت به رتبه‌های جست‌وجویم آسیب می‌زند؟",
            "acceptedAnswer": {
                "@type": "Answer",
                "text": "نه به‌شکل معناداری، به‌شرطی که دامنه، URLها و محتوا همان بمانند — گوگل URLها را ایندکس می‌کند، نه آدرس‌های IP را، و تغییر هاست به‌تنهایی یک سیگنال رتبه‌بندی نیست. ساختار URL را عیناً یکسان نگه دارید، همان کدهای وضعیت را برگردانید، و جابه‌جایی را با یک بازطراحی یا تغییر ساختار URL ترکیب نکنید. اگر در عوض دارید به یک دامنه جدید می‌روید، حتی با ریدایرکت‌های 301 درست هم انتظار یک افت موقت را داشته باشید، و بدانید که همان ریدایرکت‌ها هم دو نام را به‌شکل عمومی به هم وصل می‌کنند."
            }
        },
        {
            "@type": "Question",
            "name": "آیا باید گواهی‌های TLS را دوباره صادر کنم؟",
            "acceptedAnswer": {
                "@type": "Answer",
                "text": "بله — سرور جدید به گواهی و کلید خصوصی خودش نیاز دارد، و کپی‌کردن کلید قدیمی به جلو، حتی وقتی از نظر فنی کار می‌کند، عادت بدی است. آن را پیش از جابه‌جایی نهایی با یک چالش DNS-01 صادر کنید، که از طریق یک رکورد TXT اعتبارسنجی می‌شود و به همین دلیل، حتی وقتی رکورد A هنوز به هاست قدیم اشاره دارد هم موفق می‌شود. صبرکردن برای HTTP-01 بعد از تغییر DNS، تضمین می‌کند یک بازه از هشدارهای گواهی درست در همان پنجره‌ای که می‌خواستید محافظتش کنید، پیش بیاید."
            }
        },
        {
            "@type": "Question",
            "name": "چه زمانی کنسل‌کردن سرور قدیم امن است؟",
            "acceptedAnswer": {
                "@type": "Answer",
                "text": "بعد از یکی دو هفته لاگ‌های ساکت روی دستگاه قدیم و لاگ‌های تمیز روی دستگاه جدید — این تأخیر همان مسیر بازگشت شماست، و چند دلار هزینه دارد. پیش از کنسل‌کردن، بررسی کنید هیچ‌چیز بیرونی دیگر به IP قدیم اشاره نکند، هر رازی که تا به‌حال روی آن زندگی کرده را بچرخانید، بعد داده‌تان را حذف کنید و فضای آزاد را رونویسی کنید. کنسل‌کردن را برای آخر بگذارید. اول زدن دکمه خاتمه، پایگاه‌داده شما را روی دیسکی می‌گذارد که دیگر کنترلش دست شما نیست."
            }
        }
    ]
}
```

```json
{
    "@context": "https://schema.org",
    "@type": "BreadcrumbList",
    "itemListElement": [
        {
            "@type": "ListItem",
            "position": 1,
            "name": "خانه",
            "item": "https://servhidden.com/fa/"
        },
        {
            "@type": "ListItem",
            "position": 2,
            "name": "راهنماهای میزبانی با حریم خصوصی",
            "item": "https://servhidden.com/fa/guides"
        },
        {
            "@type": "ListItem",
            "position": 3,
            "name": "چطور یک وب‌سایت را بدون قطعی به هاست آفشور مهاجرت دهیم",
            "item": "https://servhidden.com/fa/guides/migrate-website-to-offshore-hosting"
        }
    ]
}
```