هاست اشتراکی یا سرور مجازی؟ چه زمانی وقت مهاجرت است

«هاست اشتراکی یا سرور مجازی؟» سؤالی نیست که یک‌بار برای همیشه جواب داشته باشد؛ جوابش روزی عوض می‌شود که سایت بازدید گرفته و حالا هر روز ظهر خطای ۵۰۳ می‌بینید و پشتیبانی فقط می‌گوید «مصرف CPU شما بالاست». این مقاله نشانه‌های بزرگ‌شدن از هاست اشتراکی را می‌شمارد، نشان می‌دهد کدام سهمیه پر شده و از کجا باید دیدش، و یک چک‌لیست عملی مهاجرت برای سایت‌های PHP و وردپرسی می‌دهد — با دو تله‌ی SSL و ایمیل که بیشترین مهاجرت‌ها را خراب می‌کنند.

نشانه‌هایی که می‌گوید از هاست اشتراکی بزرگ شده‌اید

هاست اشتراکی مثل واحدی در آپارتمانی شلوغ است: ارزان و بی‌دردسر، تا وقتی همسایه‌ها ساکت باشند. ده‌ها (گاهی صدها) سایت کنار هم روی یک سرور نشسته‌اند و هاستینگ با ابزارهایی مثل CloudLinux برای هرکدام سقف مصرف می‌گذارد. نشانه‌های رسیدن به سقف:

• خطای ۵۰۳ یا ۵۰۸ (Resource Limit Reached) در ساعات شلوغ — درخواست‌ها از سهمیه‌ی شما بیشترند و بازدیدکننده‌ها پشت در می‌مانند.
• کندی‌های بی‌دلیل و مقطعی — سایت تغییری نکرده اما بعضی روزها سنگین است؛ «اثر همسایه»: سایت پرمصرفِ کناری دیسک و پردازنده‌ی مشترک را می‌بلعد.
• دیوار محدودیت‌ها — نسخه‌ی PHP ثابت، max_execution_time کوتاه، ماژول‌هایی که نصب نمی‌شوند و روی بعضی هاست‌ها کران‌جابی که کوتاه‌تر از ۱۵ دقیقه اجرا نمی‌شود.
• نبود دسترسی root — Redis برای کش وردپرس؟ Node.js کنار PHP؟ جواب همیشه یکی است: «در پلن شما موجود نیست».
• آی‌پی مشترک — اگر یکی از همسایه‌ها اسپم بفرستد، آی‌پی بلک‌لیست می‌شود و ایمیل‌های شما هم به اسپم می‌روند.
• سقف اینود — علاوه بر حجم، تعداد فایل (inode) هم شمرده می‌شود؛ سایتی با ده‌ها هزار تصویر بندانگشتی پیش از پرشدن گیگابایت‌ها به این سقف می‌خورد.

اگر بیش از دو مورد آشناست، مشکل از سایت نیست؛ از ظرف است. اما پیش از تعویض ظرف بدانید کدام دیواره را فشار می‌دهید — همین یک عدد اندازه‌ی سرور بعدی را تعیین می‌کند.

خطای ۵۰۸ و ۵۰۳ از کجا می‌آید؟ کدام سهمیه پر شده است؟

روی هاست‌هایی که با CloudLinux مدیریت می‌شوند — چه cPanel و چه DirectAdmin — هر اکانت داخل محفظه‌ای جدا به نام LVE اجرا می‌شود و چند سقف مستقل دارد؛ شش سقفِ مهم اینهاست. پس «مصرف شما بالاست» عملاً بی‌معناست: هر سقف نشانه و درمان متفاوتی دارد. جدول زیر بر پایه‌ی مستندات محدودیت‌های CloudLinux است:

بیشترین سوءتفاهم روی دو سطر اول است: خطای ۵۰۸ تقریباً همیشه از EP می‌آید، نه از CPU. حتی با پردازنده‌ی خلوت، بیست بازدیدکننده‌ی هم‌زمانِ صفحه‌ای کش‌نشده سقف را پر می‌کنند — و به همین دلیل «ارتقاء به پلن بالاتر» گاهی فرقی نمی‌کند.

برای اینکه حدس نزنید، در کنترل‌پنل گزارش مصرف منابع را باز کنید: کنار مصرف هر سهمیه، تعداد «فالت» می‌گوید چند بار به آن سقف خورده‌اید. ستون با فالت غیرصفر همان دیوار است؛ باقی نویزند. مستندات CloudLinux برای یک اکانت معمولی این حدود را پیشنهاد می‌کند: ۱۰۰ درصد یک هسته، ۱ گیگابایت حافظه، ۲۰ درخواست هم‌زمان و ۱۰۰ پردازه.

تفاوت هاست و سرور مجازی در یک نگاه

تفاوت هاست و سرور مجازی در یک جمله: در هاست اشتراکی «فضایی روی سرورِ دیگران» اجاره می‌کنید، در سرور مجازی «سرورِ خودتان» را. VPS با مجازی‌سازی KVM ساخته می‌شود؛ رم و هسته‌های پردازنده واقعاً مال شماست، سیستم‌عامل را خودتان انتخاب می‌کنید و دسترسی root دارید.

پس پاسخ «هاست یا VPS» به دو چیز برمی‌گردد: چقدر منابع لازم دارید و چقدر مسئولیت می‌پذیرید. سطر ششم مهم‌ترین بهای آزادی است.

KVM چیست و چرا هر «سرور مجازی» یک چیز نیست؟

واژه‌ی «سرور مجازی» روی دو فناوری متفاوت گذاشته می‌شود. در مجازی‌سازی کانتینری (OpenVZ و LXC) همه‌ی ماشین‌ها روی یک هسته‌ی لینوکس مشترک اجرا می‌شوند؛ ماژول هسته بارگذاری نمی‌شود، بعضی sysctlها در دسترس نیست، سوآپ واقعی نیست و ارقام free گاهی رم میزبان است نه سهم شما. در KVM هر ماشین هسته‌ی خودش را بالا می‌آورد و از دید سیستم‌عامل یک سرور کامل است. برای اطمینان دو دستور کافی است:

systemd-detect-virt
kvm

lscpu | grep -iE 'hypervisor|virtualization'
Hypervisor vendor:                    KVM
Virtualization type:                  full

خروجی kvm یعنی ماشین واقعی و مجزا؛ lxc یا openvz یعنی آنچه خریده‌اید آن چیزی نیست که تصور می‌کردید. همین‌جا دیسک را هم چک کنید:

lsblk -d -o NAME,ROTA,SIZE
NAME  ROTA   SIZE
vda      0    50G

nproc
2
free -m | head -2
               total        used        free      shared  buff/cache   available
Mem:            3936         512        2870          12         554        3180

ستون ROTA برابر 0 یعنی SSD یا NVMe و 1 یعنی هارد مکانیکی. این سه عدد را در دقیقه‌ی اول تحویل سرور بررسی کنید، نه بعد از انتقال سایت.

روی VPS چه به دست می‌آورید و چه مسئولیتی می‌پذیرید؟

آزادی‌ها

روی سرور مجازی پشته‌ی نرم‌افزاری را خودتان می‌چینید: Nginx با PHP-FPM، کش آبجکت با Redis، نسخه‌ی PHP دلخواه و کران‌جاب هر دقیقه. اما مهم‌تر از آن، آزادیِ «اندازه‌گرفتن» است: روی هاست اشتراکی قربانی یک سقف نامرئی هستید، روی VPS می‌بینید چه چیزی رم را می‌خورد و کدام کوئری کند است — و بعد همان را تغییر می‌دهید.

مسئولیت‌ها

در عوض، کارهایی که تا دیروز «وظیفه‌ی هاستینگ» بود حالا وظیفه‌ی شماست — امنیت سرور لینوکس همه را قدم‌به‌قدم می‌گوید. حداقلِ روز اول چهار کار نیم‌ساعته است: ورود با کلید SSH به‌جای رمز، فایروال با فقط سه پورت باز (۲۲، ۸۰ و ۴۴۳)، به‌روزرسانی خودکار امنیتی، و یک کران‌جاب بکاپ شبانه با خروجی بیرون از سرور:

ufw default deny incoming
ufw allow OpenSSH
ufw allow 'Nginx Full'
ufw enable

sudo apt install unattended-upgrades
sudo dpkg-reconfigure --priority=low unattended-upgrades

قبل از تصمیم، این دو عدد را اندازه بگیرید

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

du -sh public_html
3.4G    public_html

mysql -u DB_USER -p -e "SELECT table_schema AS db,
  ROUND(SUM(data_length+index_length)/1024/1024,1) AS mb
  FROM information_schema.tables GROUP BY table_schema;"
+-------+-------+
| db    | mb    |
+-------+-------+
| wp_db | 412.6 |
+-------+-------+

دوم، رمی که هر درخواست PHP می‌خورد. قاعده‌ی تنظیم PHP-FPM ساده است: تعداد پردازه‌های هم‌زمان برابر است با رمِ قابل‌تخصیص، تقسیم بر رم متوسط هر پردازه. رم متوسط اندازه‌گرفتنی است:

ps -ylC php-fpm8.3 --sort:rss | awk 'NR>1 {s+=$8; n++} END {printf "%.0f MB avg over %d procs\n", s/n/1024, n}'
61 MB avg over 8 procs

حساب سرانگشتی: روی سروری با ۴ گیگابایت رم، یک تا یک‌ونیم گیگابایت را برای سیستم‌عامل، Nginx، MariaDB و حاشیه‌ی امن کنار بگذارید؛ از باقی‌مانده با میانگین ۶۰ مگابایت، حدود ۴۰ پردازه‌ی هم‌زمان درمی‌آید. این عدد را با فالت‌های EP هاست فعلی مقایسه کنید تا بدانید چه اندازه سروری مشکل را حل می‌کند و چه اندازه‌ای فقط پول اضافه است.

چک‌لیست مهاجرت از هاست به سرور برای سایت PHP و وردپرس

مهاجرت ترسناک به نظر می‌رسد، اما هفت قدم مشخص است و با رعایت ترتیب، یک دقیقه هم داون‌تایم لازم نیست:

1. صورت‌برداری کنید. نسخه‌ی PHP و اکستنشن‌های فعال (از phpinfo)، کران‌جاب‌ها و تنظیم‌های .htaccess را یادداشت کنید. همین فهرست را روی سرور جدید با php -m بگیرید و مقایسه کنید؛ ماژول جامانده شایع‌ترین علت خطای ۵۰۰ در ساعت اول است.
2. بکاپ کامل بگیرید. از کنترل‌پنل، یا اگر هاست‌تان SSH دارد:

   # on the old shared host
   mysqldump --single-transaction --default-character-set=utf8mb4 \
     -u DB_USER -p DB_NAME > site-db.sql
   tar -czf site-files.tar.gz public_html/

   --single-transaction دامپ InnoDB را بدون قفل‌کردن سایت می‌گیرد و utf8mb4 جلوی خرابی حروف فارسی را می‌گیرد.
3. سرور جدید را آماده کنید. یک VPS اوبونتو بسازید و پشته‌ی Nginx + PHP-FPM + MariaDB را بالا بیاورید؛ راه‌اندازی سایت با Nginx روی اوبونتو همین مسیر است.
4. فایل‌ها و دیتابیس را منتقل کنید. بکاپ را ببرید و برگردانید:

   # on the new VPS
   mysql -u wp_user -p wp_db < site-db.sql
   tar -xzf site-files.tar.gz -C /var/www/example.com/
   chown -R www-data:www-data /var/www/example.com/

   سپس اطلاعات اتصال را در wp-config.php هماهنگ کنید. برای سایت‌های چندگیگابایتی rsync بهتر است: بار اول همه‌چیز و دفعه‌های بعد فقط تفاوت‌ها را می‌برد، پس نسخه‌ی اولیه را یک هفته قبل ببرید و شب مهاجرت فقط تغییرات را همگام کنید:

   rsync -az --delete -e ssh public_html/ root@203.0.113.10:/var/www/example.com/

5. قبل از تغییر DNS تست کنید. فایل hosts سیستم خودتان را ویرایش کنید تا دامنه موقتاً به سرور جدید اشاره کند، بدون اینکه بقیه‌ی دنیا چیزی بفهمد:

   # local hosts file (Linux/Mac: /etc/hosts)
   # Windows: C:\Windows\System32\drivers\etc\hosts
   203.0.113.10   example.com www.example.com

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

   curl -sI --resolve example.com:80:203.0.113.10 http://example.com/ \
     | grep -Ei 'HTTP/|^server|^x-powered-by'
   HTTP/1.1 200 OK
   Server: nginx/1.24.0
   X-Powered-By: PHP/8.3.14

6. DNS را سوئیچ کنید. یکی دو روز قبل TTL رکورد A را روی عددی مثل ۳۰۰ ثانیه بگذارید؛ بعد آی‌پی را عوض کنید و SSL را فعال کنید. مهم‌تر از رکورد A، بقیه‌ی زون است: اگر زون را از نو می‌سازید، رکوردهای MX و TXT (SPF و DKIM و DMARC) و هر رکورد تأیید مالکیت را عیناً منتقل کنید — آموزش رکوردهای DNS جزئیاتشان را دارد.
7. هاست قبلی را عجله‌ای نبندید. تا چند روز هر دو را نگه دارید؛ برگشتن فقط یک تغییر DNS است. اما تا وقتی هر دو زنده‌اند بخشی از بازدیدکننده‌ها به سرور قدیمی می‌رسند؛ اگر سایت سفارش می‌گیرد، بعد از سوئیچ نوشتن روی نسخه‌ی قدیمی را ببندید تا داده‌ها دوتکه نشوند.

SSL و ایمیل: دو تله‌ای که مهاجرت را خراب می‌کنند

گواهی SSL را نمی‌توانید زودتر از DNS بگیرید

خیلی‌ها می‌خواهند پیش از سوئیچ DNS همه‌چیز — از جمله HTTPS — را آماده کنند و به بن‌بست می‌خورند. چالش پیش‌فرض Let's Encrypt یعنی HTTP-01 فایلی را زیر /.well-known/acme-challenge/ روی پورت ۸۰ می‌گذارد و از بیرون سراغش می‌رود؛ پس نام موردنظر باید همان لحظه به همان سرور برسد. طبق مستندات چالش‌های Let's Encrypt این چالش تا ۱۰ ریدایرکت را دنبال می‌کند، اما نقطه‌ی شروعش رکورد DNS فعلی است.

دو راه دارید: ترتیب را بپذیرید (اول DNS، بعد گواهی)، یا از چالش DNS-01 استفاده کنید که به‌جای فایل یک رکورد TXT روی _acme-challenge.example.com می‌خواهد و کاری به آی‌پی ندارد — مراحل هر دو در آموزش نصب SSL رایگان با Certbot آمده است.

certbot certonly --nginx -d example.com -d www.example.com --dry-run
Simulating a certificate request for example.com and www.example.com
The dry run was successful.

سرور مجازی به‌طور پیش‌فرض ایمیل نمی‌فرستد

هاست اشتراکی یک میل‌سرور آماده دارد؛ VPS خالی ندارد. اگر بعد از مهاجرت فرم تماس و ایمیل‌های سفارش قطع شد، چیزی خراب نشده — چیزی هرگز نصب نشده بود. اما مسئله فقط نصب‌نکردن نیست: بسیاری از ارائه‌دهنده‌های ابری پورت خروجی ۲۵ را روی حساب‌های تازه می‌بندند. مستندات ابری Hetzner می‌گوید پورت‌های ۲۵ و ۴۶۵ روی همه‌ی سرورهای ابری پیش‌فرض بسته‌اند و بازکردنشان پس از یک ماه سابقه و پرداخت اولین فاکتور ممکن است؛ در همان مدت پورت 587 باز است:

timeout 5 bash -c '</dev/tcp/gmail-smtp-in.l.google.com/25' && echo open || echo blocked
blocked

راه کم‌دردسر این است: رکوردهای MX را دست نزنید، و برای ایمیل‌های خروجی سایت (بازیابی رمز، فاکتور، اعلان) از یک سرویس ارسال با احراز هویت روی پورت 587 استفاده کنید. این‌طور نه اعتبار آی‌پی تازه مسئله می‌شود و نه SPF و DKIM دامنه به‌هم می‌ریزد.

بعد از مهاجرت چه چیزهایی می‌شکند و چطور درستشان کنیم؟

فهرست خرابی‌های بعد از مهاجرت کوتاه و قابل‌پیش‌بینی است؛ با یک مرور پیش از سوئیچ DNS، بیشترشان اصلاً اتفاق نمی‌افتند:

یک نکته‌ی وردپرسی: اگر برای تمرین سایت را روی دامنه‌ی موقت بالا می‌آورید، آدرس‌های داخل دیتابیس را با دست عوض نکنید — بخشی از آن‌ها داخل داده‌ی سریالایزشده‌ی PHP است. ابزار رسمی wp search-replace این حالت را می‌فهمد و با --dry-run بدون ذخیره گزارش می‌دهد:

wp search-replace 'https://example.com' 'https://staging.example.com' --all-tables --dry-run
Success: 412 replacements to be made.

با پرداخت ساعتی، مهاجرت را اول «تمرین» کنید

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

دو نکته تمرین را به کار واقعی تبدیل می‌کند. اول، روی همان اندازه‌ای تمرین کنید که قرار است بخرید؛ چیزی که می‌سنجید سرعت سایت زیر بار است، نه بالا آمدنش. دوم، خاموش‌کردن سرور محاسبه را متوقف نمی‌کند؛ آنچه متوقفش می‌کند حذف سرور است — و حذف، دیسک و همه‌ی داده‌ها را با خود می‌برد. پس پیش از حذف سرور تمرینی، کانفیگ‌هایی را که به آن رسیده‌اید (server block، تنظیم PHP-FPM، کران‌جاب‌ها) بیرون بکشید.

هاست اشتراکی یا سرور مجازی در مهران هاست؟

در سمت هاست اشتراکی، پلن‌ها روی cPanel یا DirectAdmin و در هر دو موقعیت ایران و خارج ارائه می‌شوند. کارهای روزمره از دل کنترل‌پنل انگلیسی انجام نمی‌شود: در پنل فارسی هر سرویس تب‌های جداگانه دارد — فایل‌ها، دیتابیس، FTP، دامنه‌ها، DNS، کران‌جاب، بکاپ، درخواست SSL رایگان و ایمیل. تب ایمیل همان کاری را می‌کند که نامش می‌گوید و نه بیشتر: ساخت و حذف صندوق، تغییر رمز، سهمیه و فوروارد؛ ساخت SPF و DKIM و DMARC کار این تب نیست و آن‌ها را در تب DNS به‌صورت رکورد TXT وارد می‌کنید. فهرست پلن‌ها در صفحه‌ی هاست اشتراکی است.

در سمت سرور مجازی، ماشین‌های داخل ایران روی KVM با دیسک NVMe ساخته می‌شوند و ساعتی از کیف پول کسر می‌شوند؛ سرورهای خارج در دیتاسنترهای Hetzner هستند و با همان کیف پول ریالی پرداخت می‌شوند — یعنی محدودیت پورت ۲۵ روی این دسته برقرار است. چیزی که در روز بد به دادتان می‌رسد کنسول VNC داخل پنل است: حتی وقتی شبکه‌ی سرور را با یک قاعده‌ی اشتباه فایروال قطع کرده‌اید، تصویر سرور را می‌بینید و درستش می‌کنید. کنارش نصب مجدد سیستم‌عامل، تغییر رمز root، افزودن آی‌پی، نمودار مصرف و افزودنیِ پشتیبان‌گیری خودکار هست. یک محدودیت هم صریح: منابع را فقط می‌شود افزایش داد؛ کاهش — به‌ویژه دیسک — ممکن نیست.

دو سرویس هم مستقل از این انتخاب مهاجرت را ساده‌تر می‌کنند. مدیریت DNS رکوردهای A، AAAA، CNAME، MX، TXT، NS، SRV و CAA را پوشش می‌دهد و کمترین TTL ۶۰ ثانیه است — یعنی همان کاهش TTL پیش از سوئیچ، بدون محدودیت. و کنار هر رکورد A یک کلید CDN هست که با روشن‌کردنش آی‌پی مبدأ پنهان می‌شود و پاسخ عمومی به نزدیک‌ترین نود لبه — از جمله نودهای داخل ایران — تغییر می‌کند، بدون هزینه‌ی جداگانه روی دامنه‌ای که DNS آن اینجا مدیریت می‌شود. وضعیت فعلی سایت را هم با آزمون سرعت رایگان اندازه بگیرید؛ فقط بدانید از سرور خودِ سرویس اجرا می‌شود نه از داخل ایران. جمع‌بندی: هاست اشتراکی برای شروع عالی است، اما وقتی خطای ۵۰۳ و دیوار سهمیه‌ها شروع شد، VPS ادامه‌ی طبیعی مسیر است — یک حساب بسازید و مهاجرت را بدون ریسک تمرین کنید.

سؤالات پرتکرار

هاست اشتراکی بگیرم یا سرور مجازی؟

اگر سایت تازه‌ای دارید و نمی‌خواهید وقتی صرف مدیریت سرور کنید، هاست اشتراکی انتخاب درستی است: نگهداری و امنیت سیستم‌عامل با ارائه‌دهنده است. سرور مجازی وقتی توجیه پیدا می‌کند که به سقف منابع خورده باشید، به نرم‌افزاری خارج از فهرست هاست نیاز داشته باشید یا آی‌پی اختصاصی بخواهید؛ بهای این آزادی، پذیرفتن مسئولیت به‌روزرسانی، فایروال و بکاپ است.

چه نشانه‌هایی می‌گوید وقت مهاجرت از هاست اشتراکی رسیده است؟

مهم‌ترین نشانه، تکرار خطای ۵۰۸ یا ۵۰۳ در ساعات پربازدید است؛ یعنی به سقف درخواست‌های هم‌زمان یا حافظه‌ی اکانت می‌خورید. بعدی‌ها: کندی‌های مقطعی بدون تغییر در سایت، ردشدن نصب نرم‌افزارهایی مثل Redis، و بلک‌لیست‌شدن آی‌پی مشترک. پیش از تصمیم، گزارش مصرف منابع کنترل‌پنل را باز کنید و ببینید کدام سهمیه فالت ثبت کرده است.

آیا انتقال سایت از هاست به سرور مجازی باعث قطعی می‌شود؟

لازم نیست. با ترتیب درست، داون‌تایم عملاً صفر است: اول سایت را روی سرور جدید کامل بالا بیاورید، سپس با ویرایش فایل hosts سیستم خودتان یا گزینه‌ی resolve در curl فقط برای خودتان تستش کنید، بعد TTL رکورد A را کم کنید و در آخر آی‌پی را عوض کنید. تا چند روز هاست قبلی را نگه دارید تا بازگشت فقط یک تغییر DNS باشد.

سرور مجازی برای وردپرس چقدر رم لازم دارد؟

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

بعد از مهاجرت به سرور مجازی، ایمیل‌های دامنه چه می‌شوند؟

سرور مجازی پیش‌فرض میل‌سرور ندارد، پس اگر فقط رکورد A را عوض کنید و MX را دست نزنید، ایمیل دامنه همان‌جا که بوده کار می‌کند. مشکل وقتی پیش می‌آید که زون DNS را از نو بسازید و MX و TXT را منتقل نکنید. برای ایمیل‌های خروجی سایت هم به‌جای نصب میل‌سرور از یک سرویس ارسال با احراز هویت روی پورت 587 استفاده کنید، چون پورت 25 روی بسیاری از سرورهای ابری بسته است.