نصب Apache AlmaLinux؛ راه‌اندازی Apache در AlmaLinux 9 از صفر

نصب Apache AlmaLinux وقتی نتیجه بهتری می‌دهد که آن را فقط به اجرای یک دستور نصب محدود نکنید. در AlmaLinux 9، وب‌سرور Apache با نام بسته و سرویس httpd ارائه می‌شود و اگر از همان ابتدا ساختار فایل‌ها، سرویس، فایروال، VirtualHost، مجوزها و SELinux را درست بچینید، هم اولین سایت شما سریع‌تر بالا می‌آید و هم نگه‌داری و توسعه بعدی آن ساده‌تر می‌شود. هدف این راهنما فقط روشن کردن سرویس نیست؛ می‌خواهیم یک پایه تمیز و قابل اتکا بسازیم تا بعداً افزودن دامنه‌های جدید، فعال‌سازی HTTPS، راه‌اندازی برنامه‌های وب یا عیب‌یابی خطاها دردسر کمتری داشته باشد.

در توزیع‌های خانواده RHEL، نام Apache و httpd در عمل به یک سرویس اشاره دارند. بنابراین اگر در مستندات با هر دو واژه روبه‌رو شدید، در این زمینه معمولاً منظور همان وب‌سروری است که درخواست‌های HTTP را می‌گیرد و فایل‌های ایستا یا پاسخ برنامه‌های پشت‌صحنه را تحویل می‌دهد. در AlmaLinux 9 هم همین منطق برقرار است و بیشتر دستورات مدیریتی با نام httpd انجام می‌شوند.

فرض این مقاله آن است که به یک سرور AlmaLinux 9 با دسترسی مدیریتی یا کاربری دارای sudo متصل هستید. همچنین فرض می‌کنیم می‌خواهید از صفر یک وب‌سرور عملی بسازید؛ یعنی نه‌فقط بسته را نصب کنید، بلکه بتوانید یک سایت آزمایشی بالا بیاورید، برای آن VirtualHost تعریف کنید، دسترسی شبکه را باز کنید، با SELinux هماهنگ شوید و در صورت بروز خطا بدانید از کجا باید بررسی را شروع کنید.

نصب Apache AlmaLinux: پیش‌نیازها و تصویر کلی کار

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

• بسته httpd روی سیستم نصب شده است.
• سرویس Apache با systemd فعال شده و بعد از هر راه‌اندازی مجدد سیستم هم بالا می‌آید.
• فایروال اجازه دسترسی به پورت‌های لازم را می‌دهد.
• برای سایت موردنظر یک VirtualHost مستقل تعریف شده است.
• دایرکتوری سایت، مجوزهای فایل و برچسب‌های SELinux درست تنظیم شده‌اند.
• پیکربندی با ابزارهای تست Apache بررسی شده و در صورت نیاز از روی لاگ‌ها عیب‌یابی می‌شود.

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

نصب بسته Apache و فعال‌سازی سرویس در AlmaLinux 9

اولین گام، نصب بسته وب‌سرور است. در AlmaLinux 9 این کار با dnf انجام می‌شود:

sudo dnf install httpd

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

sudo systemctl enable --now httpd

برای بررسی وضعیت سرویس، از این دستور استفاده کنید:

sudo systemctl status httpd

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

اگر هدفتان از نصب Apache AlmaLinux فقط یک تست سریع است، می‌توانید از ریشه پیش‌فرض وب‌سرور استفاده کنید که معمولاً در مسیر زیر قرار دارد:

/var/www/html/

برای نمونه، یک فایل آزمایشی ساده بسازید:

echo '<h2>Apache on AlmaLinux 9</h2>' | sudo tee /var/www/html/index.html

اما برای استفاده واقعی پس از نصب Apache AlmaLinux، بهتر است از همان ابتدا سایت خود را در یک دایرکتوری جدا و همراه با VirtualHost مستقل تعریف کنید. این کار به‌ویژه وقتی بعداً بخواهید چند سایت را روی یک سرور مدیریت کنید، بسیار مفید است.

شناخت ساختار فایل‌های Apache در AlmaLinux 9

یکی از تفاوت‌های نصب شتاب‌زده با نصب Apache AlmaLinux که بعداً قابل نگه‌داری باشد، شناخت ساختار فایل‌هاست. در AlmaLinux 9 فایل پیکربندی اصلی Apache معمولاً در این مسیر قرار دارد:

/etc/httpd/conf/httpd.conf

تنظیمات تکمیلی و فایل‌های جداگانه سایت‌ها معمولاً در این مسیر قرار می‌گیرند:

/etc/httpd/conf.d/

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

لاگ‌های Apache نیز معمولاً در این مسیر نگه‌داری می‌شوند:

/var/log/httpd/

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

ساخت دایرکتوری سایت و فایل آزمایشی

فرض کنید می‌خواهید یک سایت آزمایشی با نام example.local راه بیندازید. ساختار ساده و تمیزی مثل نمونه زیر برای شروع مناسب است:

sudo mkdir -p /var/www/example.local/public_html
sudo mkdir -p /var/www/example.local/logs

سپس یک فایل آزمایشی بسازید تا بعداً مطمئن شوید درخواست‌ها واقعاً به همین سایت هدایت می‌شوند:

cat <<'EOF' | sudo tee /var/www/example.local/public_html/index.html
<!doctype html>
<html lang="fa" dir="rtl">
<head>
  <meta charset="utf-8">
  <title>example.local</title>
</head>
<body>
  <p>سایت آزمایشی Apache روی AlmaLinux 9 فعال است.</p>
</body>
</html>
EOF

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

باز کردن فایروال و اطمینان از دسترسی شبکه

یکی از رایج‌ترین سناریوها این است که Apache روی خود سرور سالم کار می‌کند، اما از بیرون پاسخی دیده نمی‌شود. دلیل این وضعیت اغلب فایروال است. اگر firewalld فعال باشد، باید سرویس‌های موردنیاز را مجاز کنید:

sudo firewall-cmd --permanent --add-service=http
sudo firewall-cmd --permanent --add-service=https
sudo firewall-cmd --reload

برای دیدن سرویس‌های مجاز فعلی می‌توانید این دستور را اجرا کنید:

sudo firewall-cmd --list-services

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

نصب Apache AlmaLinux و تعریف VirtualHost برای اولین سایت

هسته عملی نصب Apache AlmaLinux زمانی کامل می‌شود که برای سایت خود یک VirtualHost روشن و مستقل تعریف کنید. این کار باعث می‌شود هر دامنه تنظیمات خودش را داشته باشد و در آینده افزودن سایت‌های بیشتر به‌هم‌ریختگی ایجاد نکند.

یک فایل تازه در مسیر /etc/httpd/conf.d/ بسازید:

sudo nano /etc/httpd/conf.d/example.local.conf

نمونه‌ای از پیکربندی پایه می‌تواند به این شکل باشد:

<VirtualHost *:80>
    ServerName example.local
    ServerAlias www.example.local

    DocumentRoot /var/www/example.local/public_html

    ErrorLog /var/www/example.local/logs/error.log
    CustomLog /var/www/example.local/logs/access.log combined

    <Directory /var/www/example.local/public_html>
        Options -Indexes +FollowSymLinks
        AllowOverride None
        Require all granted
    </Directory>
</VirtualHost>

در این تنظیمات، ServerName نام اصلی میزبان است و Apache بر اساس آن درخواست را با سایت درست تطبیق می‌دهد. DocumentRoot ریشه فایل‌های سایت را مشخص می‌کند. با ErrorLog و CustomLog هم لاگ‌های آن سایت را جدا می‌کنید تا بررسی خطاها ساده‌تر شود.

گزینه Options -Indexes جلوی فهرست شدن فایل‌های دایرکتوری را در صورت نبود فایل index می‌گیرد. این تنظیم ساده است، اما از نظر امنیتی و رفتاری مهم محسوب می‌شود. همچنین AllowOverride None یعنی Apache برای این مسیر سراغ .htaccess نرود. اگر کنترل کامل تنظیمات را در اختیار دارید، این رویکرد هم از نظر کارایی بهتر است و هم از نظر قابل‌پیش‌بینی بودن تنظیمات.

بعد از ذخیره فایل در فرایند نصب Apache AlmaLinux، پیش از reload یا restart حتماً صحت پیکربندی را تست کنید:

sudo apachectl configtest

اگر خروجی شامل Syntax OK بود، تغییرات را بارگذاری کنید:

sudo systemctl reload httpd

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

sudo systemctl restart httpd

مجوز فایل‌ها، مالکیت و نقش SELinux

در بسیاری از موارد، پیکربندی VirtualHost درست است اما سایت همچنان با خطاهایی مانند 403 Forbidden روبه‌رو می‌شود. در چنین وضعی باید سه لایه را از هم جدا بررسی کنید: مجوزهای کلاسیک فایل، مالکیت فایل‌ها و SELinux. اشتباه رایج این است که بدون تشخیص دقیق، مجوزها بیش از حد باز شوند یا SELinux خاموش شود. این کار شاید ظاهراً مشکل را پنهان کند، اما راه‌حل فنی درستی نیست.

تنظیم مجوزهای پایه

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

sudo find /var/www/example.local -type d -exec chmod 755 {} ;
sudo find /var/www/example.local -type f -exec chmod 644 {} ;

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

مالکیت فایل‌ها

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

بررسی SELinux

در نصب Apache AlmaLinux روی AlmaLinux 9، SELinux نقش مهمی در کنترل دسترسی دارد. حتی اگر مجوزهای سنتی لینوکسی درست باشند، یک برچسب نادرست SELinux می‌تواند مانع دسترسی Apache شود. ابتدا وضعیت SELinux را بررسی کنید:

getenforce

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

ls -lZ /var/www/example.local/public_html

اگر سایت را در مسیری متفاوت ساخته‌اید یا برچسب‌ها درست نیستند، می‌توانید نوع مناسب را تعریف و سپس آن را اعمال کنید:

sudo semanage fcontext -a -t httpd_sys_content_t "/var/www/example.local/public_html(/.*)?"
sudo restorecon -Rv /var/www/example.local/public_html

اگر دستور semanage در دسترس نبود، احتمالاً ابزارهای مربوط به سیاست SELinux نصب نیستند و باید ابتدا آن بسته‌ها را نصب کنید. نکته مهم این است که در اغلب موارد، مشکل با تنظیم درست context حل می‌شود و خاموش کردن SELinux صرفاً لایه دفاعی سیستم را تضعیف می‌کند.

تست محلی، بررسی نام میزبان و عیب‌یابی پاسخ‌ها

بعد از تعریف سایت، بهتر است پیش از تست از بیرون، ابتدا روی خود سرور پاسخ Apache را بررسی کنید. این کار کمک می‌کند بفهمید مشکل در خود وب‌سرور است یا در مسیر شبکه و DNS.

برای تست پایه:

curl -I http://127.0.0.1/
curl -I http://localhost/

اگر چند VirtualHost دارید یا می‌خواهید مطمئن شوید درخواست به سایت درست می‌رود، سرآیند میزبان را هم مشخص کنید:

curl -I -H "Host: example.local" http://127.0.0.1/

این روش بسیار مفید است، چون نشان می‌دهد Apache درخواست را به VirtualHost موردنظر شما هدایت می‌کند یا نه. اگر پاسخ 403 گرفتید، معمولاً باید مجوزها، تنظیم Require all granted و SELinux را بررسی کنید. اگر 404 گرفتید، احتمال دارد مسیر DocumentRoot اشتباه باشد یا فایل مورد انتظار در آن مسیر وجود نداشته باشد. اگر اصلاً اتصال برقرار نشد، معمولاً مسئله در سطح سرویس، پورت یا فایروال است.

بررسی لاگ‌ها

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

sudo journalctl -u httpd -xe
sudo tail -f /var/www/example.local/logs/error.log
sudo tail -f /var/www/example.local/logs/access.log

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

نکات امنیتی مهم بعد از نصب Apache AlmaLinux

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

جلوگیری از فهرست شدن دایرکتوری‌ها

اگر در یک مسیر فایل index وجود نداشته باشد، Apache بسته به تنظیمات می‌تواند فهرست فایل‌ها را نمایش دهد. در بیشتر وب‌سایت‌های عمومی این رفتار مطلوب نیست. استفاده از Options -Indexes در بلوک Directory راه ساده و موثری برای جلوگیری از این وضعیت است.

محدود کردن استفاده از .htaccess

اگر همه تنظیمات را در فایل‌های اصلی سرور مدیریت می‌کنید، فعال گذاشتن .htaccess معمولاً ضرورت ندارد. با AllowOverride None هم کنترل تنظیمات متمرکزتر می‌شود و هم Apache در هر درخواست نیازی به بررسی فایل‌های override در مسیرهای مختلف ندارد. مگر آن‌که واقعاً به این قابلیت نیاز داشته باشید، بهتر است تنظیمات را مستقیم در VirtualHost نگه دارید.

کاهش اطلاعات آشکارشده در پاسخ‌ها

برای محدود کردن اطلاعات غیرضروری در هدرها و صفحات خطا، معمولاً از این تنظیمات استفاده می‌شود:

ServerTokens Prod
ServerSignature Off

می‌توانید این تنظیمات را در یک فایل جداگانه داخل /etc/httpd/conf.d/ قرار دهید. بعد از هر تغییر نیز طبق روال همیشگی، پیکربندی را تست و سرویس را reload کنید.

نگه‌داری فایل‌های حساس خارج از DocumentRoot

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

محدود کردن نوشتن توسط وب‌سرور

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

نمونه پیکربندی تمیز برای یک سایت ایستا

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

<VirtualHost *:80>
    ServerName example.local
    DocumentRoot /var/www/example.local/public_html

    ErrorLog /var/www/example.local/logs/error.log
    CustomLog /var/www/example.local/logs/access.log combined

    ServerSignature Off

    <Directory /var/www/example.local/public_html>
        Options -Indexes +FollowSymLinks
        AllowOverride None
        Require all granted
    </Directory>
</VirtualHost>

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

اشتباه‌های رایج در راه‌اندازی اولیه

• سرویس نصب و اجرا شده، اما پورت HTTP در فایروال باز نشده است.
• DocumentRoot به مسیری اشاره می‌کند که فایل مورد انتظار در آن وجود ندارد.
• VirtualHost نوشته شده، اما قبل از reload با apachectl configtest بررسی نشده است.
• برای رفع خطای دسترسی، SELinux خاموش شده است؛ در حالی که مشکل فقط از برچسب نادرست فایل‌ها بوده.
• برای حل سریع خطا، مجوزهای بسیار باز روی فایل‌ها یا دایرکتوری‌ها اعمال شده است.
• فایل‌های حساس یا نسخه‌های پشتیبان داخل مسیر عمومی سایت نگه‌داری می‌شوند.
• بدون نیاز واقعی، وابستگی به .htaccess ایجاد شده و کنترل تنظیمات پراکنده شده است.

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

اگر بعداً HTTPS، PHP یا Reverse Proxy لازم شد

پایه‌ای که در این راهنما ساخته‌اید، برای توسعه‌های بعدی مناسب است. اگر بعداً HTTPS اضافه کنید، معمولاً یک VirtualHost جدا برای پورت 443 خواهید داشت و باید گواهی و کلید معتبر را در پیکربندی وارد کنید. اگر PHP نیاز باشد، نوع اتصال و ماژول‌های مرتبط را باید جداگانه و بر اساس مدل اجرای مدنظر خود بررسی کنید. اگر Apache قرار است نقش reverse proxy داشته باشد، باید ماژول‌ها و تنظیمات پروکسی را هم آگاهانه اضافه کنید.

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

جمع‌بندی

نصب Apache AlmaLinux فقط به معنی نصب یک بسته نیست. اگر می‌خواهید نتیجه‌ای قابل اتکا بگیرید، باید نصب سرویس، فعال‌سازی، تنظیم فایروال، تعریف VirtualHost، مدیریت مجوزها، هماهنگی با SELinux و بررسی لاگ‌ها را به‌عنوان یک زنجیره کامل ببینید. مزیت این رویکرد آن است که اولین سایت شما فقط بالا نمی‌آید، بلکه روی زیرساختی مرتب و قابل نگه‌داری قرار می‌گیرد.

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

برای مشاهده این خدمت در ماهان کلود، صفحه سرور ابری و سرور مجازی VPS را ببینید.