Blazor VPS 主機託管

UpCloud 上託管 Blazor Server 與 HTTPS

當小型 Blazor Server 應用需要獨立的 Ubuntu VPS 而非託管平台時，請參考本指南。內容涵蓋實務操作：DNS、SSH、.NET、Nginx、TLS、服務重啟、備份，以及持續擁有伺服器的成本。

起點是一台每月 約略 $109 的簡單 UpCloud 伺服器。這對於適度的生產環境啟動可能足夠，但前提是您能保持修補、監控、日誌輪替與回滾流程簡單且可重複。

查看 UpCloud 檢視先決條件 開啟 GhostlyHosting

UpCloud 推廣說明：您和我們各獲得 $909 點數。透過推薦連結購買，您的月伺服器價格不會增加。

快速解答

當控制權比平台便利更重要時，選擇 VPS

當您需要穩定成本、完整 Linux 存取、自訂 Nginx 規則、直接日誌與可檢視的部署流程時，小型 UpCloud VPS 是合適選擇。若不願意修補 Ubuntu、監控磁碟空間、測試備份或在不便時刻除錯 systemd，則不適合。

網域與 DNS SSH 金鑰存取 Nginx 搭配 TLS 您自行管理營運

適用性檢查

只有當營運工作可接受時，廉價 Blazor VPS 才有用

伺服器價格不是唯一決定因素。選擇自我主機生產應用前，請評估更新、防火牆規則、憑證、還原、日誌、監控與部署失敗的時間成本。

適合使用

當您想掌控時，選擇此路徑

  • 您需要完全掌控 Nginx、systemd、SSH、日誌、檔案與執行版本。
  • 應用程式規模適中，可從小型 VPS 開始，後續透過快照或重建擴展。
  • 您能管理 Ubuntu 更新、防火牆規則、憑證、備份、還原與監控。
  • 您需要可預測的月度基礎架構成本，而非託管平台的便利。
不適合

當營運風險較高時，選擇託管主機

  • 沒有人負責修補、備份、正常運作檢查、磁碟壓力或事件回應。
  • 應用程式需要從一開始就有託管擴展、託管資料庫、部署槽與平台支援。
  • 非技術團隊成員必須能在不操作 Linux 的情況下部署與恢復應用。
  • 短暫中斷的損失可能比託管主機費用還高。
目錄

設定前準備

先準備網域、DNS、SSH、.NET、Nginx 與 TLS 決策

大多數 VPS 啟動失敗不是 Blazor 問題，而是因為 DNS 尚未設定、SSH 存取不明確、埠口被封鎖、應用路徑臨時拼湊，或憑證設定在網域尚未指向伺服器前就開始。

DNS 前置條件

TLS 前先設定 DNS 指向

在執行 Certbot 前，請先建立最終主機名稱的 A 或 AAAA 紀錄。憑證驗證需要公開名稱正確解析。

SSH 存取

使用 SSH 金鑰與部署用戶

從金鑰存取開始，避免例行性 root 上傳，並在首次發布前決定應用目錄的擁有者。

.NET 執行環境

選擇發佈位置

在 VPS 上安裝 ASP.NET Core 執行環境。只有在您有意在伺服器上建置或發佈時，才安裝完整的 .NET SDK。

伺服器方案

僅當應用規模適中時，從每月 約略 $109 方案開始

最小方案是啟動基準，不是承諾。適合低到中等流量，主要是 Nginx 後方的靜態資產、輕量資料庫使用，以及能在記憶體或 CPU 壓力影響用戶前擴充的團隊。

方案參考 約略 $109
適用於
小型正式應用、測試環境、內部儀表板、具真實用戶的原型，以及低流量內容網站。
不建議用於
記憶體密集型應用、頻繁背景作業、大型本地資料庫、高流量尖峰，或團隊無法投入伺服器維護時間。
升級指標
當日誌與用戶時間中出現交換區使用率、CPU 飽和、佇列延遲或重啟頻率時，應考慮擴充。
01

建立伺服器

選擇最近且適用的區域、乾淨的 Ubuntu 映像檔、SSH 金鑰，以及符合啟動風險的最小方案。

02

鎖定網路

允許 SSH、HTTP 與 HTTPS。除非有特別需求，資料庫、儀表板與應用程式埠口應保持私密。

03

建立基準快照

在強化安全後且首次正式部署前，快照伺服器以加快重建速度並減少壓力。

04

記錄重建流程

將 DNS、套件、防火牆、應用路徑、服務名稱與憑證步驟整理成簡短操作手冊。

伺服器設定

修補 Ubuntu，保持公開面向小，並謹慎安裝 .NET

從乾淨的 Ubuntu 映像開始。套用更新，保持時間戳可預測，只安裝所需套件，並僅開放 SSH、HTTP 與 HTTPS。當您從工作站或 CI 發佈時，伺服器上的 SDK 是可選的。

基礎套件

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 本身不會創造排名，但能提供穩定網址、快速初次回應、正確的 HTTPS 轉址、乾淨的元資料、相符的 JSON-LD，以及比您之前使用的廉價替代方案更少的中斷，這些都有助於 SEO。

01

HTTPS 轉址

HTTP 單次轉址，保持憑證續期，避免混合內容導致頁面錯亂。

02

穩定網址

使用易讀路由，保持標準網址一致，避免每次部署後路徑變動。

03

VPS 效能

測量 TTFB，透過 Nginx 快取靜態資源，壓縮回應，確保首頁載入快速且穩定。

04

SEO 元資料

保持標題、H1、描述、Open Graph 圖片、文章結構、BreadcrumbList 與 FAQPage 結構與可見內容一致。

自動化選項

當重複手動設定風險高時，使用 GhostlyHosting

手動設定適合想了解每個細節的您。如果您已熟悉技術堆疊，並希望有可重複的部署流程，GhostlyHosting 可自動化 Ubuntu、Nginx、SSL、GitHub 及服務管理工作。

檢視 GhostlyHosting 查看 UpCloud

常見問題

我可以用每月 約略 $109 在 UpCloud 上架設 Blazor Server 嗎？

可以，適合小型應用且預期謹慎。入門方案能支援小型發布、測試環境或內部工具，但仍需監控、備份、修補與擴充計畫。

VPS 上需要完整 .NET SDK 嗎？

通常不需要。發布時從工作站或 CI 安裝 ASP.NET Core 執行環境。只有伺服器需編譯或發布時才安裝 SDK。

Kestrel 應直接對外網開放嗎？

不應。將 Kestrel 綁定 localhost，對外由 Nginx 監聽 80 與 443 埠口，負責 TLS、轉址、代理標頭與公開 URL。

廉價 Blazor VPS 主機的最大風險是什麼？

常見風險包括套件未修補、憑證過期、SSH 管理不良、缺少備份、磁碟壓力、日誌噪音，以及沒人注意服務重啟頻繁。

VPS 主機能提升 Blazor SEO 嗎？

只有在改善基礎條件時有效：穩定 HTTPS 網址、快速回應、乾淨元資料、匹配 JSON-LD、正常運作與可預期轉址。單靠主機不會是 SEO 速成。

何時應用 GhostlyHosting 而非手動操作？

手動設定適合學習或審核架構。了解流程後，想要重複使用 Ubuntu、Nginx、SSL、GitHub 與服務管理流程時，選用 GhostlyHosting。