استضافة Blazor على VPS

استضافة Blazor Server على UpCloud باستخدام Nginx و HTTPS

استخدم هذا الدليل عندما يحتاج تطبيق Blazor Server صغير إلى VPS خاص يعمل بنظام Ubuntu بدلاً من منصة مُدارة. يغطي العمل الحقيقي: DNS، SSH، .NET، Nginx، TLS، إعادة تشغيل الخدمات، النسخ الاحتياطية، والتكاليف المستمرة لامتلاك الخادم.

النقطة البداية هي خادم UpCloud بسيط بسعر تقريباً 12 ر.س.‏/شهريًا. قد يكون هذا كافيًا لإطلاق إنتاجي معتدل، ولكن فقط إذا حافظت على عادات التحديث، والمراقبة، وتدوير السجلات، والاسترجاع بسيطة وقابلة للتكرار.

تحقق من UpCloud راجع المتطلبات الأساسية افتح GhostlyHosting

ملاحظة ترويجية من UpCloud: تحصل أنت ونحن على 107 ر.س.‏ كرصيد. سعر الخادم الشهري لا يزيد بسبب رابط الإحالة.

إجابة سريعة

استخدم VPS عندما يكون التحكم أهم من سهولة المنصة

يعد VPS صغير من UpCloud مناسبًا عندما تريد تكاليف مستقرة، وصول كامل إلى Linux، قواعد Nginx مخصصة، سجلات مباشرة، وتدفق نشر يمكنك فحصه. لكنه غير مناسب إذا لم ترغب في تحديث Ubuntu، مراقبة مساحة القرص، اختبار النسخ الاحتياطية، أو تصحيح systemd في أوقات غير مناسبة.

النطاق و DNS الوصول بمفتاح SSH Nginx مع TLS العمليات التي تملكها

فحص الملاءمة

VPS رخيص لـ Blazor مفيد فقط عندما يكون العمل التشغيلي مقبولًا

سعر الخادم ليس القرار الوحيد. احسب الوقت اللازم للتحديثات، قواعد الجدار الناري، الشهادات، الاستعادة، السجلات، المراقبة، ومحاولات النشر الفاشلة قبل اختيار الاستضافة الذاتية لتطبيق إنتاجي.

ملائم جيدًا

اختر هذا المسار عندما تريد التحكم

  • تحتاج إلى تحكم كامل في Nginx وsystemd وSSH والسجلات والملفات وإصدارات وقت التشغيل.
  • التطبيق بسيط بما يكفي للبدء على VPS صغير والتوسع لاحقًا من لقطة أو إعادة بناء.
  • يمكنك التعامل مع تحديثات Ubuntu وقواعد الجدار الناري والشهادات والنسخ الاحتياطية والاستعادة والمراقبة.
  • تحتاج إلى تكاليف بنية تحتية شهرية متوقعة أكثر من سهولة منصة مُدارة.
غير مناسب

اختر الاستضافة المُدارة عندما تكون العمليات هي المخاطرة

  • لا يوجد من يتولى الترقيعات أو النسخ الاحتياطية أو فحوصات الجهوزية أو ضغط القرص أو الاستجابة للحوادث.
  • التطبيق يحتاج إلى توسع مُدار وقواعد بيانات مُدارة ومواقع نشر ودعم منصة من اليوم الأول.
  • يجب أن يتمكن الزملاء غير التقنيين من نشر واستعادة التطبيق دون التعامل مع Linux.
  • انقطاع قصير سيكون أكثر تكلفة من فاتورة استضافة مُدارة.
فهرس المحتويات

قبل الإعداد

جهز النطاق، DNS، SSH، .NET، Nginx، وقرارات TLS أولاً

معظم عمليات إطلاق VPS الفاشلة ليست بسبب Blazor. تحدث لأن DNS غير جاهز، وصول SSH غير واضح، المنافذ محجوبة، مسار التطبيق مرتجل، أو إعداد الشهادة يبدأ قبل توجيه النطاق إلى الخادم.

متطلب DNS

توجيه DNS قبل TLS

أنشئ سجل A أو AAAA لاسم المضيف النهائي قبل تشغيل Certbot. تحتاج شهادة التحقق إلى حل الاسم العام بشكل صحيح.

الوصول عبر SSH

استخدم مفاتيح SSH ومستخدم للنشر

ابدأ بالوصول عبر المفاتيح، تجنب رفع الملفات كـ root بشكل روتيني، وقرر من يملك مجلد التطبيق قبل الإصدار الأول.

بيئة تشغيل .NET

اختر مكان النشر

ثبت ASP.NET Core runtime على VPS. أضف SDK الكامل لـ .NET فقط عند البناء أو النشر المتعمد على الخادم.

خطة الخادم

ابدأ بخادم تقريباً 12 ر.س.‏/شهريًا فقط عندما يكون التطبيق بسيطًا

الخطة الأصغر هي حد أدنى للإطلاق، وليست وعدًا. تعمل بشكل أفضل لحركة مرور منخفضة إلى معتدلة، أصول ثابتة خلف Nginx، استخدام قاعدة بيانات خفيف في مكان آخر، وفريق يمكنه التوسع قبل أن يظهر ضغط الذاكرة أو المعالج للمستخدم.

مرجع الخطة تقريباً 12 ر.س.‏
استخدمه لـ
التطبيقات الإنتاجية الصغيرة، تطبيقات الاختبار، لوحات التحكم الداخلية، النماذج الأولية مع مستخدمين حقيقيين، ومواقع المحتوى منخفضة الحركة.
تجنبه لـ
التطبيقات ذات الذاكرة العالية، الوظائف الخلفية المزعجة، قواعد البيانات المحلية الكبيرة، ارتفاعات حركة المرور المفاجئة، أو الفرق التي لا تملك وقت صيانة الخادم.
إشارة للترقية
قم بالتوسع عندما تظهر مؤشرات مثل استخدام swap، تشبع المعالج، تأخير الطوابير، أو تكرار إعادة التشغيل في السجلات وأوقات المستخدم.
01

إنشاء الخادم

اختر أقرب منطقة مناسبة، صورة Ubuntu نظيفة، مفاتيح SSH، وأصغر خطة تناسب مخاطر الإطلاق.

02

قفل الشبكة

اسمح بـ SSH وHTTP وHTTPS. اجعل قواعد البيانات ولوحات التحكم ومنافذ التطبيق خاصة إلا إذا كان هناك سبب محدد.

03

التقاط لقطة أساسية

التقط لقطة للخادم بعد التقوية وقبل أول نشر إنتاجي لتسريع وإزالة توتر عمليات إعادة البناء.

04

توثيق إعادة البناء

احتفظ بخطوات DNS والحزمة والجدار الناري ومسار التطبيق واسم الخدمة والشهادة في دليل تشغيل مختصر.

إعداد الخادم

قم بتحديث Ubuntu، حافظ على السطح العام صغيرًا، وثبّت .NET بعناية

ابدأ بصورة Ubuntu نظيفة. طبق التحديثات، حافظ على توقيتات التغيير متوقعة، ثبّت فقط الحزم التي تحتاجها، وافتح فقط SSH و HTTP و HTTPS. SDK اختياري على الخادم عند النشر من محطة العمل أو CI.

الحزم الأساسية

Shell
sudo apt update && sudo apt upgrade -y
sudo apt install -y curl wget unzip apt-transport-https ca-certificates gnupg
sudo timedatectl set-timezone UTC

الجدار الناري و fail2ban

Shell
sudo apt install -y ufw fail2ban
sudo ufw default deny incoming
sudo ufw default allow outgoing
sudo ufw allow ssh
sudo ufw allow http
sudo ufw allow https
sudo ufw enable
sudo systemctl enable --now fail2ban

حزم .NET

Shell
wget https://packages.microsoft.com/config/ubuntu/24.04/packages-microsoft-prod.deb -O packages-microsoft-prod.deb
sudo dpkg -i packages-microsoft-prod.deb
rm packages-microsoft-prod.deb
sudo apt update
sudo apt install -y aspnetcore-runtime-8.0

تدفق النشر

انشر محليًا، ارفع بشكل متوقع، ودع systemd يتحكم في عملية التطبيق

بالنسبة لخادم صغير، أبسط طريقة نشر يدوية وأكثرها أمانًا هي: بناء إصدار Release، رفعه إلى مجلد معروف، تشغيل التطبيق كمستخدم مخصص، وجعل systemd مسؤولًا عن إعادة التشغيل والسجلات.

النشر والرفع

Shell
# Build locally
dotnet publish -c Release -o publish

# Copy to UpCloud (replace user@host)
rsync -avz --delete publish/ user@YOUR_UPCLOUD_IP:/var/www/blazor-app/releases/current/

# On the server, set ownership
sudo useradd -m -s /bin/bash blazorapp || true
sudo chown -R blazorapp:blazorapp /var/www/blazor-app

خدمة systemd

systemd
[Unit]
Description=Blazor Server on UpCloud
After=network.target

[Service]
User=blazorapp
WorkingDirectory=/var/www/blazor-app/releases/current
ExecStart=/usr/bin/dotnet /var/www/blazor-app/releases/current/YourApp.dll --urls http://127.0.0.1:5001
Restart=always
RestartSec=5
Environment=ASPNETCORE_URLS=http://127.0.0.1:5001

[Install]
WantedBy=multi-user.target

Nginx وTLS

وضع Kestrel خلف Nginx وجعل HTTPS هو المسار العام الوحيد

يجب أن يستمع Kestrel على localhost. يستقبل Nginx حركة المرور العامة، يعيد توجيه HTTP إلى HTTPS، ينهي TLS، يمرر المضيف والبروتوكول الأصليين، ويحافظ على ثبات عنوان URL للمستخدمين ومحركات البحث.

وكيل عكسي Nginx

nginx
server {
    listen 80;
    listen [::]:80;
    server_name app.example.com;
    return 301 https://$host$request_uri;
}

server {
    listen 443 ssl http2;
    listen [::]:443 ssl http2;
    server_name app.example.com;

    ssl_certificate     /etc/letsencrypt/live/app.example.com/fullchain.pem;
    ssl_certificate_key /etc/letsencrypt/live/app.example.com/privkey.pem;

    add_header Strict-Transport-Security "max-age=63072000; includeSubDomains" always;

    location / {
        proxy_pass         http://127.0.0.1:5001;
        proxy_http_version 1.1;
        proxy_set_header   Upgrade $http_upgrade;
        proxy_set_header   Connection "keep-alive";
        proxy_set_header   Host $host;
        proxy_set_header   X-Real-IP $remote_addr;
        proxy_set_header   X-Forwarded-For $proxy_add_x_forwarded_for;
        proxy_set_header   X-Forwarded-Proto $scheme;
        proxy_cache_bypass $http_upgrade;
    }
}

أوامر Certbot

Shell
sudo apt install -y certbot python3-certbot-nginx
sudo certbot --nginx -d app.example.com --redirect --agree-tos -m [email protected]
sudo certbot renew --dry-run

العمليات

حافظ على تكاليف صادقة من خلال التخطيط للصيانة قبل وصول الحركة

فاتورة VPS الشهرية متوقعة. أما تكلفة العمليات فهي غير متوقعة ما لم تجعلها روتينية: تحديثات الأمان، فحص تجديد الشهادات، تدوير السجلات، تنبيهات القرص، اللقطات، اختبارات الاستعادة، وعملية تراجع سريعة للإصدارات الفاشلة.

تحديثات Ubuntu

تحديثات مجدولة

قم بتشغيل تحديثات الحزم خلال نافذة مخططة، ثم تحقق من خدمة Blazor، حالة Nginx، ومسار تجديد الشهادة.

استعادة النسخ الاحتياطية

اختبر الاستعادة، لا تكتفِ بإنشاء اللقطات فقط

اللقطات مفيدة فقط عند استعادة واحدة منها. احتفظ بملفات التطبيق، الأسرار، ونسخ قواعد البيانات ضمن خطة الاسترداد.

سجلات الخادم

راقب الأخطاء غير الظاهرة

استخدم journalctl، سجلات Nginx، تنبيهات القرص، وفحوصات التشغيل حتى لا تبقى عمليات النشر الفاشلة أو حركة البوتات مخفية.

توسيع VPS

قم بالتوسيع قبل أن يشعر المستخدمون بذلك

انتقل إلى خطة أكبر، قسم الخدمات، أضف CDN، أو استنسخ من لقطة قبل أن يؤدي ضغط الذاكرة إلى توقف الخدمة.

واقع SEO

الاستضافة تدعم SEO فقط عندما تبقى الأساسيات مستقرة

لا يخلق VPS ترتيبًا بمفرده. لكنه يساعد عندما يوفر عناوين URL مستقرة، استجابات أولى سريعة، إعادة توجيه HTTPS صحيحة، بيانات وصفية نظيفة، JSON-LD متطابق، وانقطاعات أقل من الحلول الأرخص التي كنت تستخدمها سابقًا.

01

إعادة توجيه HTTPS

أعد توجيه HTTP مرة واحدة، حافظ على تجديد الشهادات، وتجنب الأصول المختلطة التي تجعل الصفحات تبدو معطلة.

02

عناوين URL مستقرة

استخدم مسارات سهلة القراءة، حافظ على اتساق عناوين URL الرسمية، وتجنب مسارات النشر التي تتغير بعد كل إصدار.

03

أداء VPS

قِس وقت وصول أول بايت (TTFB)، خزّن الأصول الثابتة عبر Nginx، ضغط الاستجابات، وحافظ على سرعة تحميل الصفحة الأولى بشكل ثابت.

04

بيانات تعريف SEO

حافظ على توافق العنوان، H1، الوصف، صورة Open Graph، مخطط المقال، BreadcrumbList، ومخطط FAQPage مع المحتوى المرئي.

خيار الأتمتة

استخدم GhostlyHosting عندما يكون تكرار الإعداد اليدوي هو الجزء الأكثر خطورة

الإعداد اليدوي مفيد لفهم كل جزء متحرك. إذا كنت تعرف التقنية وتريد مسار نشر موجه وقابل للتكرار، يمكن لـ GhostlyHosting أتمتة سير عمل Ubuntu وNginx وSSL وGitHub وإدارة الخدمة.

راجع GhostlyHosting تحقق من UpCloud

الأسئلة الشائعة

هل يمكنني استضافة Blazor Server على UpCloud مقابل تقريباً 12 ر.س.‏/شهرياً؟

نعم، لتطبيق بسيط مع توقعات محسوبة. الخطة الأساسية تدعم إطلاقًا صغيرًا، بيئة اختبار، أو أداة داخلية، لكنك تحتاج إلى مراقبة، نسخ احتياطية، تحديثات، وخطة للتوسيع.

هل أحتاج إلى تثبيت .NET SDK كامل على VPS؟

عادة لا. ثبت وقت تشغيل ASP.NET Core عند النشر من محطة العمل أو CI. ثبت SDK فقط عندما يبني الخادم التطبيق أو ينشره عن قصد.

هل يجب تعريض Kestrel مباشرة على الإنترنت؟

لا. اربط Kestrel بـ localhost وعرّض Nginx على المنافذ 80 و443. يتولى Nginx التعامل مع TLS، إعادة التوجيه، رؤوس البروكسي، والواجهة العامة لعناوين URL.

ما هي أكبر مخاطر استضافة Blazor VPS الرخيصة؟

المخاطر الشائعة تشمل الحزم غير المحدثة، الشهادات المنتهية، ضعف أمان SSH، نقص النسخ الاحتياطية، ضغط القرص، السجلات الصاخبة، وعدم ملاحظة إعادة تشغيل الخدمة المتكررة.

هل تحسن استضافة VPS من SEO الخاص بـ Blazor؟

فقط عندما تحسن الإعدادات الأساسيات: عناوين HTTPS مستقرة، استجابات سريعة، بيانات تعريف نظيفة، JSON-LD متطابق، وقت تشغيل مستقر، وإعادة توجيه متوقعة. الاستضافة وحدها ليست اختصارًا لـ SEO.

متى يجب استخدام GhostlyHosting بدلاً من الإعداد اليدوي؟

استخدم الإعداد اليدوي للتعلم أو تدقيق البنية. استخدم GhostlyHosting عندما تريد سير عمل قابل للتكرار على Ubuntu، Nginx، SSL، GitHub، وإدارة الخدمة بعد فهم المكونات.