رفتن به محتوای اصلی
Persian Extreme CloudPersian Extreme Cloud | پرشین کلود
Persian Extreme Cloud | پرشین کلود

راه‌اندازی سایت با Nginx و گواهی SSL رایگان در اوبونتو

در این آموزش یک سایت HTML ساده روی Nginx راه‌اندازی و با Certbot برای آن HTTPS فعال می‌کنیم. مثال برای اوبونتوی تازه است؛ روی سروری که وب‌سایت واقعی یا کنترل‌پنل دارد، فایل‌های سایت و تنظیمات موجود را جایگزین نکنید. نصب PHP یا وردپرس موضوع این مقاله نیست.

۱. دامنه و شبکه را آماده کنید

دامنه باید متعلق به شما باشد. رکورد A آن را به IPv4 سرور و فقط در صورت وجود IPv6 درست، رکورد AAAA را به IPv6 متصل کنید. پورت‌های TCP 80 و 443 باید در فایروال سیستم و پنل مجاز باشند. دسترسی SSH را حفظ کنید؛ مراحل در آموزش UFW آمده است.

در همهٔ مثال‌ها example.com نام نمونه است؛ آن را با دامنهٔ خود جایگزین کنید. برای صدور گواهی به دامنهٔ نمونه درخواست نفرستید. اگر CDN دارید، مسیر اعتبارسنجی و تنظیم TLS آن را هم بررسی کنید.

۲. نصب Nginx و ساخت صفحه

sudo apt update
sudo apt install nginx
sudo systemctl status nginx --no-pager
sudo mkdir -p /var/www/example.com/html
sudo nano /var/www/example.com/html/index.html

در فایل، این صفحهٔ ساده را ذخیره کنید:

<!doctype html>
<html lang="fa" dir="rtl">
<meta charset="utf-8">
<title>سایت من</title>
<h1>سایت آزمایشی آماده است</h1>
</html>

فایل باید برای Nginx قابل خواندن باشد؛ برای رفع خطای مجوز، همهٔ مسیرها را 777 نکنید. مالکیت و مجوز مناسب همان پروژه را تعیین کنید.

۳. تنظیم سایت

فایل جدید /etc/nginx/sites-available/example.com را با sudo nano باز کنید و محتوای زیر را بگذارید. اگر فایلی با این نام دارید، ابتدا آن را بخوانید و نسخهٔ پشتیبان بگیرید:

server {
    listen 80;
    server_name example.com;
    root /var/www/example.com/html;
    index index.html;

    location / {
        try_files $uri $uri/ =404;
    }
}

اگر عمداً سایت را روی IPv6 هم ارائه می‌کنید، listen [::]:80 را به همین بلوک اضافه کنید و دسترسی IPv6 را آزمایش کنید. سپس فقط اگر لینک مقصد از قبل وجود ندارد:

sudo ln -s /etc/nginx/sites-available/example.com /etc/nginx/sites-enabled/example.com
sudo nginx -t

اگر تست موفق بود، تنظیم را بارگذاری کنید:

sudo systemctl reload nginx
curl -I -H "Host: example.com" http://127.0.0.1/

سایت را از مرورگر با http:// و دامنهٔ واقعی باز کنید. پاسخ سایت پیش‌فرض می‌تواند نشان‌دهندهٔ اشتباه server_name یا دامنه باشد؛ برای رفع آن، همهٔ تنظیمات دیگر را حذف نکنید.

۴. نصب Certbot و دریافت گواهی

روش این بخش snap رسمی Certbot است. ابتدا snapd و پشتیبانی classic باید آماده باشند. اگر Certbot با روش دیگری نصب شده، طبق مستند رسمی یک روش نصب واحد انتخاب کنید و نسخه‌های موازی نسازید. برای نصب تازه:

sudo snap install --classic certbot
sudo /snap/bin/certbot --nginx -d example.com

دستور دوم فقط با دامنهٔ واقعی و پس از دسترسی عمومی HTTP اجرا شود. ایمیل معتبر بدهید، شرایط سرویس را بخوانید و تصمیم مربوط به هدایت HTTP به HTTPS را آگاهانه انتخاب کنید. Certbot می‌تواند تنظیم Nginx را ویرایش کند؛ قبل از آن نسخهٔ پشتیبان داشته باشید.

۵. بررسی HTTPS و تمدید

sudo nginx -t
curl -I https://example.com/
sudo /snap/bin/certbot certificates
sudo /snap/bin/certbot renew --dry-run
systemctl list-timers --all

در مرورگر دامنه و گواهی را بررسی کنید. dry-run آزمون تمدید است و جای پایش تاریخ انقضا را نمی‌گیرد. نصب Certbot معمولاً زمان‌بندی تمدید دارد؛ وجود و اجرای آن را کنترل کنید. مسیر اعتبارسنجی مورد استفاده باید در تمدیدهای بعد هم قابل دسترس بماند.

۶. خطاهای رایج

Timeout اعتبارسنجی: رکورد دامنه، مسیر شبکه و پورت 80 را بررسی کنید. AAAA اشتباه: وجود IPv6 نادرست می‌تواند اعتبارسنجی را مختل کند. 404: root، نام فایل و server_name را بررسی کنید. 502: اگر reverse proxy دارید، برنامهٔ پشت آن را بررسی کنید. خطای گواهی: نام دامنه، تاریخ اعتبار و ساعت سیستم را ببینید؛ هشدار را دور نزنید.

sudo tail -n 50 /var/log/nginx/error.log
sudo journalctl -u nginx --since "15 minutes ago" --no-pager

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

منابع و ادامهٔ یادگیری

مبنای مثال‌های سرور، اوبونتو ۲۴٫۰۴ LTS است؛ نام سرویس‌ها و روش نصب در توزیع‌های دیگر ممکن است متفاوت باشد. تصویر مقاله مفهومی است. این دستورها هنگام تهیهٔ مقاله روی سرویس واقعی مشتری اجرا نشده‌اند.

منابع رسمی: راهنمای Nginx، دستورالعمل رسمی Certbot

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

نصب Docker و اجرای برنامه با Docker Compose در اوبونتو

با Docker Compose می‌توانید تنظیم اجرای برنامه را در یک فایل نگه دارید. این آموزش روی اوبونتوی تازه و پشتیبانی‌شده، یک وب‌سرور نمونه را اجرا می‌کند. برای سروری که Docker یا برنامهٔ واقعی دارد، ابتدا وضعیت و بکاپ را بررسی کنید؛ بسته‌ها یا داده‌های موجود را کورکورانه حذف نکنید.

۱. نسخه و پیش‌نیازها

cat /etc/os-release
uname -m
docker --version
docker compose version

اگر Docker نصب نیست، دو دستور آخر خطا می‌دهند که طبیعی است. نسخهٔ اوبونتو و معماری باید در فهرست پشتیبانی رسمی Docker باشند. نصب‌های قدیمی و بسته‌های متعارض را مطابق مستند رسمی بررسی کنید؛ این مقاله فرض می‌کند ماشین تازه است.

۲. نصب از مخزن رسمی Docker

دستورهای زیر کلید و مخزن رسمی را اضافه می‌کنند. قبل از اجرا، محتوای فایل موجود docker.sources را بررسی کنید تا تنظیم قبلی را ناخواسته جایگزین نکنید:

sudo apt update
sudo apt install ca-certificates curl
sudo install -m 0755 -d /etc/apt/keyrings
sudo curl -fsSL https://download.docker.com/linux/ubuntu/gpg -o /etc/apt/keyrings/docker.asc
sudo chmod a+r /etc/apt/keyrings/docker.asc
sudo tee /etc/apt/sources.list.d/docker.sources <<EOF
Types: deb
URIs: https://download.docker.com/linux/ubuntu
Suites: $(. /etc/os-release && echo "${UBUNTU_CODENAME:-$VERSION_CODENAME}")
Components: stable
Architectures: $(dpkg --print-architecture)
Signed-By: /etc/apt/keyrings/docker.asc
EOF
sudo apt update
sudo apt install docker-ce docker-ce-cli containerd.io docker-buildx-plugin docker-compose-plugin

سپس وضعیت را بررسی کنید:

sudo systemctl status docker --no-pager
sudo docker version
sudo docker compose version

در این آموزش از sudo استفاده می‌کنیم. عضویت در گروه docker دسترسی بسیار قدرتمندی به میزبان می‌دهد؛ آن را معادل یک دسترسی عادی و بی‌خطر تلقی نکنید.

۳. پروژهٔ نمونه بسازید

mkdir -p ~/px-demo/html
cd ~/px-demo
printf "<h1>PXCloud Docker test</h1>\n" > html/index.html
nano compose.yaml

محتوای زیر را در compose.yaml قرار دهید. فاصله‌گذاری YAML مهم است. برچسب stable-alpine برای مثال آموزشی است؛ در محیط عملیاتی نسخه یا digest بررسی‌شده را ثابت کنید:

services:
  web:
    image: nginx:stable-alpine
    ports:
      - "127.0.0.1:8080:80"
    volumes:
      - ./html:/usr/share/nginx/html:ro
    restart: unless-stopped

۴. اجرا و بررسی نتیجه

sudo docker compose config
sudo docker compose up -d
sudo docker compose ps
curl http://127.0.0.1:8080/
sudo docker compose logs --tail=50 web

دستور up در صورت نیاز ایمیج را دانلود می‌کند. باید متن صفحهٔ آزمایشی را ببینید. پورت 8080 عمداً فقط روی localhost منتشر شده و از اینترنت مستقیم باز نمی‌شود. برای نمایش امن در مرورگر رایانه، می‌توانید از تونل SSH استفاده کنید یا پس از طراحی دسترسی، Nginx را به‌عنوان reverse proxy تنظیم کنید.

۵. فایل‌ها و دادهٔ پایدار

پوشهٔ html روی میزبان باقی می‌ماند و فقط خواندنی به کانتینر متصل شده است. داده‌ای که صرفاً داخل لایهٔ نوشتنی کانتینر باشد ممکن است با جایگزینی کانتینر از بین برود. برای دیتابیس، volume مناسب و بکاپ سازگار لازم است؛ داشتن volume خودِ بکاپ نیست. رمزها را در فایل عمومی یا مخزن کد قرار ندهید.

۶. توقف و به‌روزرسانی

sudo docker compose stop
sudo docker compose start

برای به‌روزرسانی، ابتدا بکاپ و تغییرات نسخه را بررسی کنید، سپس در محیط آزمایشی pull و up را امتحان کنید:

sudo docker compose pull
sudo docker compose up -d

این کار ممکن است کانتینر را دوباره بسازد. دستور down کانتینر و شبکهٔ پروژه را جمع می‌کند؛ افزودن -v می‌تواند volumeها را هم حذف کند. در این آموزش از -v و پاک‌سازی عمومی prune استفاده نمی‌کنیم.

۷. فایروال و خطاهای رایج

پورت‌های منتشرشدهٔ Docker ممکن است از قواعد معمول UFW عبور کنند. قبل از تغییر 127.0.0.1 به انتشار عمومی، محدودیت‌های Docker و فایروال بیرونی را بررسی و از شبکهٔ دیگر تست کنید. اگر port already allocated دیدید، با ss سرویس اشغال‌کننده را پیدا کنید؛ آن را حدسی متوقف نکنید. برای permission denied مسیر volume، مالکیت و مجوزها را بررسی کنید و از chmod 777 به‌عنوان راه‌حل عمومی استفاده نکنید.

آموزش‌های UFW، Nginx و SSL و بکاپ لینوکس مکمل این مطلب‌اند.

منابع و ادامهٔ یادگیری

مبنای مثال‌های سرور، اوبونتو ۲۴٫۰۴ LTS است؛ نام سرویس‌ها و روش نصب در توزیع‌های دیگر ممکن است متفاوت باشد. تصویر مقاله مفهومی است. این دستورها هنگام تهیهٔ مقاله روی سرویس واقعی مشتری اجرا نشده‌اند.

منابع رسمی: نصب رسمی Docker، Docker Compose، فایروال Docker

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

بکاپ و بازیابی فایل‌های لینوکس با rsync و tar

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

۱. داده و مقصد را مشخص کنید

فایل‌های سایت، تنظیمات و دادهٔ برنامه را فهرست کنید. مقصد روی همان VPS در برابر حذف یا خرابی خود VPS کافی نیست. دسترسی مقصد را محدود کنید و حجم آزاد را بررسی کنید. برای دیتابیس فعال از dump یا ابزار بکاپ سازگار همان دیتابیس استفاده کنید؛ کپی خام فایل‌های در حال تغییر ممکن است نسخه‌ای ناسازگار بسازد.

۲. یک آرشیو آزمایشی بسازید

این مثال فقط پوشهٔ آزمایشی در خانهٔ کاربر ایجاد می‌کند و فایل‌های سیستم را تغییر نمی‌دهد:

mkdir -p ~/backup-demo/source ~/backup-demo/archives ~/backup-demo/restore
printf "PXCloud backup test\n" > ~/backup-demo/source/example.txt
tar -czf ~/backup-demo/archives/files.tar.gz -C ~/backup-demo/source .
tar -tzf ~/backup-demo/archives/files.tar.gz

گزینهٔ c ساخت، z فشرده‌سازی gzip، f نام فایل و t فهرست‌کردن محتواست. با -C مسیر پایه را تعیین کرده‌ایم تا نام‌های داخل آرشیو نسبی باشند. آرشیو مقصد را داخل پوشه‌ای که از آن بکاپ می‌گیرید نسازید.

۳. بازیابی را در پوشهٔ جدا امتحان کنید

tar -xzf ~/backup-demo/archives/files.tar.gz -C ~/backup-demo/restore
cat ~/backup-demo/restore/example.txt
sha256sum ~/backup-demo/archives/files.tar.gz

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

۴. انتقال با rsync؛ ابتدا dry-run

روی دستگاهی که rsync و دسترسی SSH به مقصد دارد، مقصد متعلق به خودتان را وارد کنید. پوشهٔ مقصد باید از قبل وجود داشته و برای کاربر مقصد قابل نوشتن باشد؛ rsync معمولاً در هر دو طرف لازم است:

rsync -avhn -e "ssh -p 22" ~/backup-demo/archives/ BACKUP_USER@BACKUP_HOST:/backup/my-vps/

n یعنی فقط پیش‌نمایش. پس از بررسی مسیر و فایل‌ها، همان دستور را بدون n اجرا کنید:

rsync -avh -e "ssh -p 22" ~/backup-demo/archives/ BACKUP_USER@BACKUP_HOST:/backup/my-vps/

اسلش انتهای مسیر مبدأ مهم است: اینجا محتوای archives منتقل می‌شود. انتقال روی SSH رمزگذاری می‌شود، ولی فایل ذخیره‌شده در مقصد لزوماً رمزگذاری‌شده نیست. حفظ مالکیت و مجوزها به دسترسی مقصد بستگی دارد؛ برای بکاپ سیستمی باید ACL، xattr و نیاز برنامه جدا بررسی شوند.

۵. چرا –delete را در مثال نگذاشتیم؟

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

۶. زمان‌بندی را پس از آزمون دستی اضافه کنید

ابتدا اسکریپت بکاپ را دستی اجرا و کد خروج و لاگ را بررسی کنید. سپس با cron یا systemd timer، با مسیرهای مطلق و کاربر دارای حداقل مجوز زمان‌بندی کنید. برای انتقال خودکار، کلید اختصاصی و محدودشده به مقصد لازم است؛ رمز را داخل اسکریپت ننویسید. اجرای هم‌زمان دو نوبت، پرشدن دیسک و شکست شبکه باید کنترل و گزارش شوند.

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

۷. بازیابی واقعی چه ترتیبی دارد؟

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

منابع و ادامهٔ یادگیری

مبنای مثال‌های سرور، اوبونتو ۲۴٫۰۴ LTS است؛ نام سرویس‌ها و روش نصب در توزیع‌های دیگر ممکن است متفاوت باشد. تصویر مقاله مفهومی است. این دستورها هنگام تهیهٔ مقاله روی سرویس واقعی مشتری اجرا نشده‌اند.

منابع رسمی: مرجع rsync، راهنمای GNU tar

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

امن‌سازی SSH؛ ورود با کلید و محدودکردن root بدون قطع دسترسی

برای امن‌سازی SSH، ابتدا مسیر ورود جایگزین را بسازید و آزمایش کنید؛ سپس روش قدیمی را محدود کنید. این راهنما برای اوبونتوی ساده با ورود کلیدی است. اگر MFA، LDAP یا سیاست سازمانی دارید، تنظیمات احراز هویت را بدون تطبیق تغییر ندهید.

۱. کاربر مدیریتی مستقل بسازید

روی سرور، نام cloudadmin نمونه است. اگر حساب مناسب از قبل دارید، همان را استفاده کنید:

sudo adduser cloudadmin
sudo usermod -aG sudo cloudadmin

رمز قوی کاربر را در مدیر رمز نگه دارید. داشتن کلید SSH لزوماً درخواست رمز sudo را حذف نمی‌کند. از پنجره‌ای دیگر با همین کاربر وارد شوید و sudo -v را آزمایش کنید. حساب root را هنوز نبندید.

۲. روی دستگاه خود کلید بسازید

در PowerShell ویندوز یا ترمینال لینوکسِ دستگاه خود:

ssh-keygen -t ed25519 -C "my-admin-device"

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

۳. کلید عمومی را به حساب درست اضافه کنید

در لینوکسِ رایانه، اگر ssh-copy-id نصب است، با پورت واقعی اجرا کنید:

ssh-copy-id -i ~/.ssh/id_ed25519.pub -p 22 cloudadmin@SERVER_IP

در ویندوز می‌توانید محتوای فایل عمومی را با Get-Content بخوانید و در نشست همان کاربر روی سرور، یک خط به authorized_keys اضافه کنید. فایل موجود را جایگزین نکنید:

mkdir -p ~/.ssh
chmod 700 ~/.ssh
nano ~/.ssh/authorized_keys
chmod 600 ~/.ssh/authorized_keys

دستورهای بالا باید در حساب مقصد اجرا شوند؛ اگر در root هستید، مسیر ~ متعلق به root است. کلید عمومی باید یک خط کامل باشد. مالک پوشه و فایل باید همان کاربر مقصد باشد.

۴. ورود کلیدی را واقعاً آزمایش کنید

از پنجرهٔ جدید دستگاه خود با مسیر کلید خصوصی وارد شوید. در ویندوز مسیر را متناسب با پوشهٔ کاربر بنویسید:

ssh -i ~/.ssh/id_ed25519 -o PreferredAuthentications=publickey -o PasswordAuthentication=no -p 22 cloudadmin@SERVER_IP

بعد از ورود، whoami و sudo -v را بررسی کنید. اگر کلید یا sudo کار نمی‌کند، ادامه ندهید. روش اتصال اولیه در راهنمای SSH در ویندوز و گوشی آمده است.

۵. تنظیمات مؤثر SSH را بررسی کنید

sudo sshd -T
sudo grep -RniE "^(Include|Match|PasswordAuthentication|KbdInteractiveAuthentication|PermitRootLogin|PubkeyAuthentication)" /etc/ssh/sshd_config /etc/ssh/sshd_config.d

در OpenSSH معمولاً اولین مقدار به‌دست‌آمده ملاک است؛ اضافه‌کردن یک فایل با نام دلخواه لزوماً تنظیم قبلی را تغییر نمی‌دهد. فایل‌های Include و بخش‌های Match را بررسی کنید. از فایل‌هایی که قرار است تغییر دهید نسخهٔ پشتیبان خارج از پوشهٔ فعال تنظیمات بگیرید.

۶. ورود با رمز و root را محدود کنید

فقط پس از موفقیت مرحلهٔ چهار، تنظیمات زیر را در محل مناسب پیکربندی اعمال کنید. غیرفعال‌کردن keyboard-interactive برای این سناریوی صرفاً کلیدی است؛ در سناریوی MFA ممکن است لازم باشد روشن بماند:

PubkeyAuthentication yes
PasswordAuthentication no
KbdInteractiveAuthentication no
PermitRootLogin no

پیش از اعمال، صحت نحو و سپس تنظیم مؤثر را بررسی کنید. برای قواعد Match، sshd -T -C با مشخصات واقعی user،host و addr لازم است. اگر خروجی مطابق انتظار نیست، تغییر را اعمال نکنید:

sudo sshd -t
sudo sshd -T | grep -E "^(pubkeyauthentication|passwordauthentication|kbdinteractiveauthentication|permitrootlogin)"

فقط اگر بررسی موفق بود، روی اوبونتو سرویس را reload کنید و اتصال جدید بگیرید:

sudo systemctl reload ssh

۷. آزمون نهایی و راه بازگشت

اتصال تازهٔ کلیدی و sudo باید کار کنند؛ ورود با رمز و root باید طبق سیاست رد شود. نشست قبلی را تنها پس از این آزمون ببندید. در صورت خطا، از همان نشست یا کنسول، فایل تغییرکرده را به نسخهٔ قبلی برگردانید، sshd -t بگیرید و دوباره reload کنید. خودکار فرض نکنید که فایل نسخهٔ پشتیبان داخل sshd_config.d بی‌اثر است.

برای محدودکردن شبکهٔ مبدأ، راهنمای UFW را ببینید. تغییر پورت به‌تنهایی جای احراز هویت قوی نیست. دسترسی همکاران را با کلید جداگانه مدیریت کنید تا هنگام لغو دسترسی، کلید همه عوض نشود.

منابع و ادامهٔ یادگیری

مبنای مثال‌های سرور، اوبونتو ۲۴٫۰۴ LTS است؛ نام سرویس‌ها و روش نصب در توزیع‌های دیگر ممکن است متفاوت باشد. تصویر مقاله مفهومی است. این دستورها هنگام تهیهٔ مقاله روی سرویس واقعی مشتری اجرا نشده‌اند.

منابع رسمی: OpenSSH در اوبونتو، مرجع sshd_config

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

آموزش فایروال UFW در اوبونتو؛ بازکردن پورت بدون قطع SSH

UFW ابزاری برای مدیریت ساده‌تر فایروال اوبونتو است. هدف این راهنما بازگذاشتن فقط دسترسی‌های لازم است، نه اجرای یک مجموعه قانون یکسان روی همهٔ سرورها. مثال‌ها برای یک VPS ساده هستند؛ روی سرور دارای Docker، VPN، مسیریابی یا تنظیمات موجود، ابتدا طراحی فعلی را بررسی کنید.

۱. وضعیت فعلی را ثبت کنید

sudo ufw status verbose
sudo ss -lntp
cat /etc/default/ufw

اگر UFW نصب نیست، روی اوبونتو با sudo apt install ufw آن را نصب کنید. وجود فایروال دیگری مثل firewalld یا قواعد سفارشی را بررسی کنید؛ چند مدیر فایروال را بدون طراحی هم‌زمان فعال نکنید. مقدار IPv6 و آدرس‌های فعال را ببینید؛ IPv6 را صرفاً برای ساده‌شدن کار حذف نکنید.

۲. اول دسترسی SSH را اجازه دهید

فقط اگر SSH واقعاً روی TCP پورت 22 است:

sudo ufw allow 22/tcp comment "SSH access"

اگر پورت متفاوت است، همان شماره را جایگزین کنید. پروفایل OpenSSH معمولاً پورت پیش‌فرض را توصیف می‌کند؛ برای پورت سفارشی به آن اتکا نکنید. این قاعده اجازهٔ اتصال به پورت می‌دهد، اما جای احراز هویت امن را نمی‌گیرد.

۳. پورت‌های برنامه را اضافه کنید

برای وب‌سروری که قرار است HTTP و HTTPS عمومی ارائه دهد:

sudo ufw allow 80/tcp comment "HTTP"
sudo ufw allow 443/tcp comment "HTTPS"

اگر وب‌سرور ندارید، این پورت‌ها را صرفاً به خاطر مثال باز نکنید. پایگاه داده را بی‌دلیل روی اینترنت عمومی نگذارید. TCP و UDP یکسان نیستند و باید پروتکل موردنیاز برنامه را بشناسید.

۴. سیاست پیش‌فرض و فعال‌سازی

برای سرور ساده‌ای که سرویس ورودی دیگری ندارد، پس از ثبت همهٔ اجازه‌های لازم:

sudo ufw default deny incoming
sudo ufw default allow outgoing
sudo ufw enable
sudo ufw status verbose

پیام تأیید را بخوانید. یک اتصال SSH تازه از دستگاه خود باز کنید؛ زنده‌ماندن اتصال قبلی به‌تنهایی کافی نیست. وب‌سایت یا سرویس‌های مجاز را از بیرون هم آزمایش کنید. در سرور مسیریاب یا VPN، سیاست forwarded traffic نیازمند طراحی جداست.

۵. محدودکردن SSH به IP مدیر

اگر IP ثابت معتبر دارید، می‌توانید یک اجازهٔ محدود اضافه کنید. 203.0.113.10 در مثال زیر آدرس مستنداتی است و باید با IP عمومی واقعی مدیر جایگزین شود:

sudo ufw allow from 203.0.113.10 to any port 22 proto tcp comment "Admin SSH"
sudo ufw status numbered

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

۶. حذف قاعده و بازیابی اشتباه

با sudo ufw status numbered شمارهٔ فعلی را بخوانید و سپس sudo ufw delete NUMBER را با شمارهٔ واقعی اجرا کنید. بعد از هر حذف، شماره‌ها را دوباره بخوانید. از ufw reset برای اصلاح یک قانون استفاده نکنید، چون کل قواعد را پاک می‌کند.

اگر دسترسی قطع شد، از کنسول وارد شوید و اجازهٔ پورت واقعی SSH را اصلاح کنید. خاموش‌کردن دائمی فایروال راه‌حل نهایی نیست. فایروال پنل دیتاسنتر هم مستقل است و ممکن است اتصال را مسدود کند.

۷. Docker و IPv6 را فراموش نکنید

طبق مستند Docker، انتشار پورت کانتینر می‌تواند از قواعد معمول UFW عبور کند. امنیت پورت‌های کانتینر را با قواعد مناسب Docker و تست بیرونی بررسی کنید. در آموزش Docker Compose مثال را روی localhost قرار داده‌ایم. قواعد IPv6 و رکورد AAAA سایت نیز باید با سیاست دسترسی هماهنگ باشند.

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

منابع و ادامهٔ یادگیری

مبنای مثال‌های سرور، اوبونتو ۲۴٫۰۴ LTS است؛ نام سرویس‌ها و روش نصب در توزیع‌های دیگر ممکن است متفاوت باشد. تصویر مقاله مفهومی است. این دستورها هنگام تهیهٔ مقاله روی سرویس واقعی مشتری اجرا نشده‌اند.

منابع رسمی: فایروال اوبونتو، Docker و فایروال

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

بررسی مصرف CPU، RAM و دیسک لینوکس؛ پیدا کردن علت کندی سرور

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

۱. نمای کلی سرور

date -Is
uptime
nproc
free -h
df -h
df -i

uptime میانگین بار را نشان می‌دهد، نه درصد مصرف CPU. آن را با تعداد پردازنده‌های قابل استفاده و وضعیت انتظار I/O تفسیر کنید. df -h ظرفیت فایل‌سیستم و df -i مصرف inode را نشان می‌دهد؛ ممکن است با وجود فضای خالی، تعداد زیاد فایل‌های کوچک inodeها را پر کرده باشد.

۲. پردازش پرمصرف را پیدا کنید

top
ps -eo pid,comm,%cpu,%mem --sort=-%cpu | head -n 15
ps -eo pid,comm,%cpu,%mem --sort=-%mem | head -n 15

در top با q خارج شوید. PID و نام پردازش را ثبت و مالک سرویس را مشخص کنید. درصد CPU ابزارها همیشه بر یک مبنای یکسان نیست؛ پردازش چندریسمانی ممکن است بیش از 100 درصد نشان داده شود. یک پردازش پایگاه دادهٔ فعال را صرفاً به دلیل مصرف بالا kill نکنید؛ ممکن است در حال انجام کار ضروری باشد.

۳. کمبود RAM را از کش تشخیص دهید

free -h
vmstat 1 5

در free ستون available برای تخمین حافظهٔ قابل استفاده مهم‌تر از نگاه‌کردن صرف به free است. لینوکس از حافظه برای کش هم استفاده می‌کند. در vmstat، فعالیت مداوم si و so همراه کندی می‌تواند نشانهٔ جابه‌جایی حافظه با Swap باشد؛ اولین سطر نمای متفاوتی از سطرهای نمونه‌برداری بعدی دارد. Swap جایگزین RAM کافی نیست.

برای بررسی رخدادهای کمبود حافظه، لاگ کرنل را بخوانید و دنبال پیام‌های OOM بگردید:

sudo journalctl -k --since "1 hour ago" --no-pager

۴. پوشه‌ها و فایل‌های حجیم

ابتدا همان فایل‌سیستم پرشده را هدف بگیرید. مثال زیر /var را بررسی می‌کند؛ اجرای du روی حجم‌های بزرگ ممکن است خودش I/O ایجاد کند:

sudo du -xhd1 /var | sort -h
sudo find /var/log -xdev -type f -size +100M -printf "%s %p\n"
sudo journalctl --disk-usage

گزینهٔ -x از عبور به فایل‌سیستم دیگر جلوگیری می‌کند. اندازهٔ find برحسب بایت است. قبل از حذف، معلوم کنید فایل متعلق به چه برنامه‌ای است و سیاست نگهداری چیست. فایل دیتابیس، فایل فعال برنامه و پوشه‌های Docker را دستی پاک نکنید. برای لاگ‌ها، تنظیم چرخش و مدت نگهداری راه‌حل اصولی‌تری است.

۵. چرا df و du عدد یکسان ندارند؟

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

sudo lsof +L1

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

۶. آیا گلوگاه دیسک است؟

اگر ابزار iostat از بستهٔ sysstat در دسترس است:

iostat -xz 1 5

تأخیر و صف را در کنار بار برنامه بررسی کنید. یک درصد utilization بالا برای همهٔ انواع ذخیره‌سازی یک تفسیر یکسان ندارد. روی VPS، رفتار میزبان و محدودیت‌های پلن هم مؤثرند. بدون شواهد، نتیجه نگیرید که حتماً دیسک خراب است یا باید پلن عوض شود.

۷. اقدام بعدی بر اساس شواهد

برای CPU بالا، درخواست‌ها و پردازش‌ها؛ برای RAM کم، مصرف برنامه و OOM؛ برای دیسک پر، منشأ رشد فایل؛ و برای تأخیر شبکه، راهنمای شبکه را بررسی کنید. پیش از پاک‌سازی یا تغییر مهم، بکاپ مستقل داشته باشید. اگر بعد از اصلاح برنامه هنوز ظرفیت کافی نیست، منابع لازم را با اندازه‌گیری انتخاب کنید.

منابع و ادامهٔ یادگیری

مبنای مثال‌های سرور، اوبونتو ۲۴٫۰۴ LTS است؛ نام سرویس‌ها و روش نصب در توزیع‌های دیگر ممکن است متفاوت باشد. تصویر مقاله مفهومی است. این دستورها هنگام تهیهٔ مقاله روی سرویس واقعی مشتری اجرا نشده‌اند.

منابع رسمی: راهنمای free، راهنمای top

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

عیب‌یابی اینترنت، DNS و پورت‌های سرور لینوکس

وقتی سایت یا SSH باز نمی‌شود، تغییر تصادفی DNS و خاموش‌کردن فایروال معمولاً تشخیص را سخت‌تر می‌کند. در این آموزش عیب‌یابی شبکهٔ لینوکس را از رابط و مسیر تا نام دامنه، پورت و برنامه پیش می‌بریم. فقط مقصد متعلق به خودتان یا مقصد مجاز را آزمایش کنید؛ مثال‌ها جایگزین بررسی تنظیمات سرویس نیستند.

۱. دامنهٔ مشکل را محدود کنید

مشخص کنید مشکل برای همهٔ کاربران است یا یک شبکه؛ فقط دامنه باز نمی‌شود یا IP هم در دسترس نیست؛ و از چه زمانی شروع شده است. تغییر اخیر در DNS، فایروال، برنامه یا گواهی را یادداشت کنید. یک خطای HTTPS با قطع کامل اینترنت یکسان نیست.

۲. آدرس و مسیر شبکه را بخوانید

ip -br address
ip route
ip -6 route

رابط مورد انتظار، آدرس اختصاص‌یافته و مسیر پیش‌فرض را با اطلاعات سرویس مقایسه کنید. وجود آدرس خصوصی در بعضی طراحی‌ها طبیعی است؛ آن را بدون دانستن معماری حذف نکنید. در شبکه‌های /32 یا Gateway خارج از subnet، تنظیم راهنمای همان سرویس ملاک است.

برای آزمایش ICMP از ping -c 4 همراه IP مجاز استفاده کنید. پاسخ‌ندادن Ping به‌تنهایی قطع شبکه را ثابت نمی‌کند؛ ICMP ممکن است مسدود باشد. بهتر است اتصال TCP به پورت مورد انتظار را هم بررسی کنید.

۳. DNS را جداگانه بررسی کنید

getent ahosts example.com
resolvectl status
resolvectl query example.com

example.com را با دامنهٔ خود جایگزین کنید. getent مسیر معمول حل نام سیستم را بررسی می‌کند؛ resolvectl در سیستم‌های دارای systemd-resolved کاربرد دارد. نبودن این ابزار الزاماً خطای DNS نیست. آدرس برگشتی را با IP مورد انتظار مقایسه کنید و رکوردهای A و AAAA را جدا در نظر بگیرید.

اگر IP کار می‌کند و فقط نام حل نمی‌شود، تنظیم resolver یا رکورد دامنه را بررسی کنید. فایل resolv.conf ممکن است توسط سرویس شبکه مدیریت شود؛ بازنویسی دستی آن می‌تواند موقت یا اشتباه باشد.

۴. آیا برنامه روی پورت گوش می‌دهد؟

sudo ss -lntp
sudo ss -lnup

خروجی اول سوکت‌های TCP در حال گوش‌دادن و پردازش مربوط را نشان می‌دهد؛ دومی UDP را بررسی می‌کند. آدرس 127.0.0.1 یعنی سرویس فقط از خود ماشین قابل دسترسی است. 0.0.0.0 معمولاً همهٔ رابط‌های IPv4 را شامل می‌شود؛ این به‌تنهایی بازبودن فایروال بیرونی را ثابت نمی‌کند.

۵. برنامه را از داخل سرور آزمایش کنید

برای یک وب‌سرور HTTP محلی روی پورت 80:

curl -I --connect-timeout 5 http://127.0.0.1/
systemctl status nginx --no-pager
sudo journalctl -u nginx --since "15 minutes ago" --no-pager

نام nginx صرفاً مثال است؛ سرویس واقعی خود را بررسی کنید. خطای 404 نشان می‌دهد یک پاسخ HTTP رسیده ولی مسیر پیدا نشده؛ 502 یا 504 می‌تواند به ارتباط با برنامهٔ پشت وب‌سرور مربوط باشد. قبل از Restart، لاگ مرتبط را بخوانید.

۶. تست بیرونی و فایروال

از رایانهٔ ویندوزی با PowerShell پورت واقعی را بررسی کنید:

Test-NetConnection SERVER_IP -Port 22

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

sudo ufw status verbose
sudo ufw status numbered

در IPv6 هم مسیر و قواعد را بررسی کنید. برای تشخیص اختلاف IPv4/IPv6 در یک سایت از curl -4 و curl -6 استفاده کنید. شکست IPv6 در سیستمی که IPv6 ندارد طبیعی است. برای تغییر قواعد، آموزش UFW را ببینید.

۷. تست HTTPS بدون دست‌کاری DNS

اگر IP جدید وب‌سرور را دارید، با دامنهٔ واقعی و IP واقعی می‌توان DNS را فقط برای همان درخواست کنار گذاشت و نام TLS را حفظ کرد:

curl -I --connect-timeout 5 --resolve example.com:443:SERVER_IP https://example.com/

SERVER_IP را جایگزین کنید. برای نادیده‌گرفتن خطای گواهی از -k به‌عنوان راه‌حل استفاده نکنید؛ نام دامنه، اعتبار گواهی و ساعت سیستم را بررسی کنید. راهنمای Nginx و HTTPS این بخش را تکمیل می‌کند.

چه اطلاعاتی برای پشتیبانی آماده کنیم؟

زمان خطا، مبدأ تست، مقصد و پورت، متن دقیق خطا و نتیجهٔ تست محلی و بیرونی را ثبت کنید. لاگ‌ها را قبل از ارسال از رمز، توکن، کوکی و اطلاعات شخصی پاک کنید. این شواهد بسیار مفیدتر از عبارت «اینترنت سرور قطع است» هستند.

منابع و ادامهٔ یادگیری

مبنای مثال‌های سرور، اوبونتو ۲۴٫۰۴ LTS است؛ نام سرویس‌ها و روش نصب در توزیع‌های دیگر ممکن است متفاوت باشد. تصویر مقاله مفهومی است. این دستورها هنگام تهیهٔ مقاله روی سرویس واقعی مشتری اجرا نشده‌اند.

منابع رسمی: ابزار ss، فایروال اوبونتو

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

اتصال به سرور لینوکس با SSH در ویندوز، اندروید و آیفون

برای مدیریت سرور لینوکس با SSH به IP یا دامنهٔ سرور، پورت SSH، نام کاربری و رمز یا کلید مجاز نیاز دارید. SSH محیط خط فرمان را در اختیار شما می‌گذارد؛ مانند Remote Desktop، دسکتاپ گرافیکی نمایش نمی‌دهد. اطلاعات اتصال را از جزئیات همان سرویس بگیرید؛ کاربر همیشه root و پورت همیشه 22 نیست.

۱. پیش از اولین اتصال

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

۲. اتصال از ویندوز

Windows Terminal یا PowerShell را باز کنید و ابتدا وجود OpenSSH Client را بررسی کنید. اگر دستور شناخته نشد، OpenSSH Client را از Optional features ویندوز نصب کنید؛ برای اتصال به لینوکس به نصب SSH Server روی ویندوز نیاز ندارید.

ssh -V
ssh -p 22 USER@SERVER_IP

USER نام کاربر و SERVER_IP آدرس سرویس است. عدد 22 فقط نمونهٔ پورت پیش‌فرض است. هنگام درخواست رمز، تایپ شما معمولاً نمایش داده نمی‌شود؛ این رفتار طبیعی است. پس از ورود با دستورهای زیر نام کاربر و سرور را کنترل کنید:

whoami
hostname
pwd

۳. پیام اثر انگشت را کورکورانه تأیید نکنید

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

sudo ssh-keygen -lf /etc/ssh/ssh_host_ed25519_key.pub

اگر هشدار تغییر کلید دیدید، ابتدا دلیل را بررسی کنید؛ نصب مجدد می‌تواند علت باشد، اما همیشه چنین نیست. حذف رکورد قبلی بدون بررسی یا غیرفعال‌کردن StrictHostKeyChecking راه‌حل امنی نیست.

۴. اتصال با اندروید

یک کلاینت SSH معتبر نصب کنید؛ برای نمونه نسخهٔ رسمی Termius برای اندروید. در بخش Hosts یک میزبان جدید بسازید، Address، Port و Username را مطابق سرویس وارد کنید و روش Password یا Key را انتخاب کنید. پس از ذخیره، میزبان را باز و اثر انگشت را تطبیق دهید. نام منوها ممکن است با نسخه تغییر کند.

۵. اتصال با آیفون

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

۶. ورود با کلید و انتقال فایل

اگر کلید عمومی قبلاً روی حساب سرور ثبت شده است، از ویندوز با مسیر کلید خصوصی وارد شوید. فایل .pub کلید عمومی است و برای گزینهٔ -i استفاده نمی‌شود:

ssh -i "C:\Users\YOUR_NAME\.ssh\id_ed25519" -p 22 USER@SERVER_IP

برای ارسال یک فایل از PowerShell، دستور زیر را روی رایانهٔ خود اجرا کنید. در scp گزینهٔ پورت، P بزرگ است؛ مقصد نمونه پوشهٔ خانهٔ کاربر است:

scp -P 22 .\example.txt USER@SERVER_IP:~/

برای ایجاد و ثبت کلید، آموزش امن‌سازی SSH را دنبال کنید. در موبایل، قابلیت SFTP به برنامه و امکانات آن بستگی دارد.

۷. خطای اتصال را درست تشخیص دهید

Timeout: آدرس، پورت، مسیر شبکه و فایروال را بررسی کنید. Connection refused: سرویس ممکن است گوش ندهد یا اتصال صریحاً رد شود. Permission denied: نام کاربر و روش احراز هویت را بررسی کنید؛ عوض‌کردن DNS معمولاً این خطا را حل نمی‌کند. Could not resolve hostname: نام دامنه یا DNS را بررسی کنید.

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

منابع و ادامهٔ یادگیری

مبنای مثال‌های سرور، اوبونتو ۲۴٫۰۴ LTS است؛ نام سرویس‌ها و روش نصب در توزیع‌های دیگر ممکن است متفاوت باشد. تصویر مقاله مفهومی است. این دستورها هنگام تهیهٔ مقاله روی سرویس واقعی مشتری اجرا نشده‌اند.

منابع رسمی: SSH در ویندوز، راهنمای OpenSSH

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

پیش از خرید سرور مجازی چه چیزهایی را بررسی کنیم؟

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

اگر هنوز بین VPS و سرور اختصاصی مردد هستید، ابتدا مقایسهٔ سرور مجازی و اختصاصی را بخوانید. برای بررسی گزینه‌های فعلی نیز فهرست پلن‌های سرور مجازی در دسترس است.

۱. کاربرد و نیاز واقعی را مشخص کنید

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

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

۲. CPU و RAM را فراتر از عدد مقایسه کنید

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

در محاسبهٔ حافظه، سیستم‌عامل، سرویس‌های جانبی و کش را هم در نظر بگیرید. پلنی که فقط حداقل RAM اعلام‌شدهٔ نرم‌افزار را دارد، ممکن است هنگام به‌روزرسانی یا افزایش بار کم بیاورد. از فروشنده دربارهٔ شرایط افزایش منابع و توقف احتمالی سرویس سؤال کنید.

۳. دیسک، فضای قابل استفاده و رشد داده را بررسی کنید

نوع دیسک و ظرفیت آن را از مشخصات پلن بخوانید. نام NVMe به‌تنهایی تضمین سرعت مشخص برای هر VPS نیست؛ محدودیت‌های I/O و الگوی کار برنامه هم اثر دارند. بخشی از فضای دیسک را سیستم‌عامل و فایل‌های جانبی مصرف می‌کنند؛ لاگ‌ها، به‌روزرسانی‌ها و نسخه‌های پشتیبان محلی را در برآورد فراموش نکنید.

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

۴. لوکیشن را بر اساس کاربران و سرویس مقصد انتخاب کنید

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

برای مقایسه می‌توانید سرور مجازی رسپینا، ترکیه، هلند و آلمان را بررسی کنید. دسترسی به یک سایت یا سرویس ثالث را صرفاً بر اساس کشور IP قطعی ندانید؛ سیاست آن سرویس و وضعیت IP نیز اهمیت دارد.

۵. پورت، ترافیک و IP سه موضوع جدا هستند

  • سرعت پورت: ظرفیت اتصال اعلام‌شده را با سرعت اختصاصی و تضمین‌شده اشتباه نگیرید.
  • ترافیک: حجم مجاز، دورهٔ محاسبه و اینکه ورودی، خروجی یا مجموع آن‌ها محاسبه می‌شود را بررسی کنید.
  • مصرف اضافه: بپرسید پس از پایان سهمیه، سرویس محدود می‌شود، متوقف می‌شود یا هزینهٔ اضافه دارد.
  • IP: تعداد IPv4 و IPv6، اختصاصی‌بودن آدرس و شرایط IP اضافه یا تعویض آن را بخوانید.

آپ‌لینک پرظرفیت یک دیتاسنتر به معنی دریافت همان ظرفیت روی تک‌تک سرویس‌ها نیست. اگر عبارت «نامحدود» دیدید، سیاست مصرف منصفانه و محدودیت‌های استفاده را هم بررسی کنید. برای کاربرد حساس، پاسخ روشن دربارهٔ همان پلن بگیرید.

۶. سیستم‌عامل، معماری و لایسنس را تطبیق دهید

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

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

۷. مسئول مدیریت و محدودهٔ پشتیبانی را بدانید

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

وجود کنسول، نصب مجدد سیستم‌عامل و روش بازیابی دسترسی را بررسی کنید. نصب مجدد می‌تواند داده‌ها را حذف کند؛ پیش از استفاده، پیام تأیید و شرایط همان سرویس را بخوانید. برای ویندوز، راهنمای اتصال با Remote Desktop به شروع کار کمک می‌کند.

۸. بکاپ و سررسید را از روز اول جدی بگیرید

وجود بکاپ را فرض نکنید. اگر ارائه می‌شود، فاصلهٔ تهیه، مدت نگهداری، محل ذخیره و هزینهٔ بازیابی را بپرسید. نسخه‌ای مستقل از داده‌های مهم خارج از همان سرور نگه دارید و بازیابی آن را آزمایش کنید. برای RouterOS، آموزش Backup و Export میکروتیک را بخوانید.

مهلت تعلیق، تمدید و حذف برای همهٔ سرویس‌ها یکسان نیست. زمان دقیق انقضا، شرایط تمدید دیرهنگام و هشدارهای فاکتور همان سرویس را ملاک قرار دهید. به یک مهلت عمومی مثل «سه روز برای همهٔ سرورها» اتکا نکنید و تمدید را به آخرین لحظه موکول نکنید.

چک‌لیست نهایی قبل از پرداخت

  1. کاربرد، سیستم‌عامل و معماری سازگار را مشخص کرده‌ام.
  2. منابع معمول، اوج مصرف و فضای رشد را برآورد کرده‌ام.
  3. لوکیشن، پورت، سهمیهٔ ترافیک و شرایط مصرف اضافه روشن است.
  4. هزینهٔ لایسنس، IP اضافه، مدیریت و بکاپ را بررسی کرده‌ام.
  5. روش دسترسی، کنسول و بازیابی را می‌دانم.
  6. محدودهٔ پشتیبانی و شرایط تغییر پلن را خوانده‌ام.
  7. دورهٔ پرداخت، سررسید و شرایط تعلیق یا حذف همان سرویس روشن است.
  8. برای اطلاعات مهم نسخهٔ پشتیبان مستقل دارم.

پرسش‌های رایج پیش از خرید VPS

ارزان‌ترین پلن برای شروع کافی است؟

فقط اگر نیاز نرم‌افزار و مصرف شما را پوشش دهد. کمبود منابع و هزینهٔ مهاجرت می‌تواند صرفه‌جویی اولیه را از بین ببرد.

آیا هر زمان بخواهم می‌توانم منابع را افزایش دهم؟

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

برای انتخاب دقیق‌تر چه اطلاعاتی به پشتیبانی بدهم؟

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

تفاوت سرور مجازی و اختصاصی؛ کدام برای شما مناسب است؟

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

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

سرور مجازی یا VPS چیست؟

با مجازی‌سازی، یک میزبان فیزیکی می‌تواند چند ماشین مجازی با سیستم‌عامل و محیط اجرایی جدا داشته باشد. سهم CPU، حافظه، دیسک و سیاست اشتراک منابع را باید از مشخصات همان پلن بخوانید. داشتن دسترسی مدیریتی داخل VPS به معنی کنترل کامل سخت‌افزار میزبان نیست. مرجع مقایسهٔ VPS و سرور اختصاصی در AWS

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

سرور اختصاصی چیست؟

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

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

جدول مقایسهٔ سرور مجازی و اختصاصی

معیار سرور مجازی سرور اختصاصی
زیرساخت ماشین مجازی روی میزبان یک ماشین فیزیکی برای مشتری
شروع پروژه معمولاً هزینهٔ ورود کمتر تعهد هزینهٔ بیشتر برای ظرفیت کامل
کنترل سخت‌افزار محدود به امکانات ارائه‌شده بیشتر، طبق قرارداد سرویس
افزایش منابع وابسته به پلن و امکان تغییر آن ممکن است نیازمند تغییر قطعه یا مهاجرت باشد
عملکرد وابسته به منابع و سیاست میزبان وابسته به سخت‌افزار و پیکربندی
مدیریت و امنیت در سرویس مدیریت‌نشده با مشتری در سرویس مدیریت‌نشده با مشتری
بکاپ باید وجود و شرایط آن بررسی شود باید وجود و شرایط آن بررسی شود

آیا سرور اختصاصی همیشه سریع‌تر است؟

خیر. مقایسهٔ «VPS» با «Dedicated» بدون دانستن سخت‌افزار کافی نیست. یک برنامه ممکن است به سرعت تک‌هسته، دیگری به RAM و سومی به تأخیر دیسک حساس باشد. تعداد هسته به‌تنهایی معیار عملکرد نیست؛ برای انتخاب، مصرف واقعی برنامه را اندازه بگیرید و نتیجه را با منابع پلن تطبیق دهید.

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

هزینهٔ واقعی را چطور مقایسه کنیم؟

فقط قیمت ماهانهٔ سرور را نبینید. هزینهٔ لایسنس سیستم‌عامل و نرم‌افزار، بکاپ خارج از سرور، مدیریت، IP اضافه و ترافیک مازاد احتمالی را هم بررسی کنید. اگر مهاجرت لازم شود، زمان تیم و توقف احتمالی سرویس هم بخشی از هزینه است. نرخ و امکانات هر سرویس را از صفحهٔ همان پلن یا پیش‌فاکتور بگیرید؛ قیمت ثابت عمومی برای همهٔ پروژه‌ها وجود ندارد.

  • پردازنده: مصرف معمول و اوج، تعداد پردازش‌های هم‌زمان و حساسیت به تک‌هسته.
  • حافظه: RAM واقعی برنامه، کش و فضای رشد.
  • دیسک: ظرفیت، سرعت موردنیاز، رشد داده و نسخه‌های پشتیبان.
  • شبکه: نزدیکی به کاربران، تأخیر، حجم انتقال و سیاست مصرف.
  • عملیات: مسئول به‌روزرسانی، امنیت، پایش و بازیابی چه کسی است؟

چه زمانی VPS انتخاب مناسب‌تری است؟

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

نوع سیستم‌عامل را هم با نرم‌افزار هماهنگ کنید: سرور مجازی لینوکس برای بسیاری از ابزارهای وب و توسعه مناسب است و سرور مجازی ویندوز برای برنامه‌هایی که به Windows نیاز دارند بررسی می‌شود. هزینه و شرایط لایسنس را در سفارش بخوانید.

چه زمانی سرور اختصاصی را بررسی کنیم؟

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

برای راه‌اندازی چند ماشین مجازی روی سرور اختصاصی، صرفاً ظرفیت RAM و دیسک کافی نیست؛ مجازی‌سازی، شبکه، تخصیص IP، امنیت و مجوزهای نرم‌افزاری هم باید طراحی شوند. این انتخاب برای تیمی که توان نگهداری ندارد ممکن است پیچیدگی بیشتری از ارزش آن ایجاد کند.

سه سناریوی ساده برای تصمیم‌گیری

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

پرسش‌های رایج

آیا دسترسی root یعنی سرور اختصاصی داریم؟

خیر؛ روی بسیاری از VPSها هم دسترسی مدیریتی سیستم‌عامل وجود دارد. این دسترسی مدل تخصیص سخت‌افزار را تغییر نمی‌دهد.

آیا اختصاصی امن‌تر است؟

جداسازی سخت‌افزاری یک ویژگی است، اما امنیت به مدیریت دسترسی، به‌روزرسانی، فایروال و بکاپ هم وابسته است. هیچ‌کدام بدون پیکربندی درست مصون نیستند.

آیا بعداً می‌توان از VPS مهاجرت کرد؟

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

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

مجوزها و نمادهای اعتماد

برای بررسی اعتبار، روی نماد کلیک کنید.

نماد اعتماد الکترونیکی PXCloud
نماد اعتماد الکترونیکی