2026 年 Pelican 與 Pterodactyl 對比：功能、效能與 VPS 規格需求

VPS SOS 編輯團隊原創大约 21 分鐘

Pelican 和 Pterodactyl 解決的是同一個基本問題：讓使用者透過瀏覽器管理遊戲伺服器，由獨立服務負責主機上的容器。選擇哪一款，會影響管理流程、整合和升級，但不會自動改變 Minecraft 世界的 tick 速度，或 Rust 伺服器能夠承載的玩家數量。

如果優先考慮保留成熟的現有部署，選擇 Pterodactyl 穩定版 1.x；如果看重 Pelican 的管理流程、外掛系統和身分驗證選項，則可以評估 Pelican。 至於兩款面板底層的基礎設施，當區域部署和靈活計費符合社群需求時，我們綜合推薦 LightNode。

選定面板後，如需更深入地比較主機方案，可閱讀已有的 Pelican Panel 代管供應商推薦指南和 Pterodactyl Panel 代管供應商推薦指南。

核查日期：2026 年 10 月 16 日。本文結合上游文件、發行說明、部署分析和可重現的評估方案撰寫。我們沒有為本文執行付費 VPS 基準測試，也沒有編造回應時間、記憶體測量結果或供應商效能評分。

首先，比較正確的版本

“Pelican 與 Pterodactyl 對比”已不再只是新介面與一成不變的舊面板之間的比較。

項目或分支	核查時的發行資訊	應如何理解
Pelican Panel	發佈頁將 v1.0.0-rc.1 列為最新版本	驗收測試時應考慮 RC 標記，不能把它描述為已經成熟的 1.0 正式版
Pterodactyl 1.x	v1.15.1 被標記為最新穩定版	作為成熟正式部署的比較基線
Pterodactyl 2.0	v2.0.0-beta.2 被列為預覽版本	在測試面板上單獨評估；上游目前建議正式環境面板繼續使用 1.x

來源：Pelican 發行版本和 Pterodactyl 發行版本。這是特定日期的版本快照，不意味著應長期固定安裝這些建置。

Pterodactyl 2.0 引入擴展、主題、統一的管理端與使用者端應用，以及 egg 目錄。因此，籠統地說“Pterodactyl 沒有擴展系統”並不準確。比較功能時，應區分穩定分支和測試分支。

架構：Panel、Wings、Docker 與 Egg

可以將部署理解為兩條路徑：

Administration:
Browser -> HTTPS reverse proxy -> Panel -> Wings API

Gameplay:
Player -> game allocation on a node -> Docker container -> game process

Panel 負責 Web 介面和管理請求；Wings 執行在每個遊戲節點上，控制容器。Egg 描述安裝和啟動行為，包括容器映像檔和變量。Pelican 起源於 Pterodactyl 的分支，保留了這種總體職責劃分。參見 Pelican 架構概覽和 Pterodactyl 文件。

一台 VPS 可以同時執行這兩個組件。規模較大時，可將 Panel 放在獨立機器上，在其他位置增加 Wings 節點。對於常見的遊戲連接埠直連方式，遊戲流量不經過 Panel Web 伺服器。讓 Panel 更靠近管理員，不會讓遠端遊戲節點也更靠近玩家。

實際意義： 應分別比較儀錶盤回應和遊戲效能。登錄頁緩慢、控制台連接延遲和遊戲 tick 耗時突增，可能由不同原因造成。

功能：哪些差異真正重要？

方面	Pelican	Pterodactyl 穩定版 1.x	對選購或維運的影響
核心管理	Panel 與 Wings 架構；Docker 工作負載	Panel 與 Wings 架構；Docker 工作負載	兩者都需要合適節點、連接埠分配和持續維護的遊戲定義
管理介面	基於 Filament 的介面；管理員角色和權限	成熟的管理流程	透過實際員工任務體驗，而非只看截圖
擴展能力	生態中的第一方外掛與主題	現有修改和第三方整合需檢查版本	遷移前清點每項整合
身分驗證	文件介紹 passkey、OAuth 和雙因素驗證	覈實所選版本及新增的身分驗證整合	同時測試帳號還原和代理設定
組織方式	使用標籤，替代舊的 nests/locations 模型	現有流程使用 nests 和 locations	自動化部署可能需要調整
備份	文件介紹按節點設定本機和 S3 儲存	覈實部署版本的備份設定	兩款面板都不能免去還原測試
大版本方向	需檢查 RC 及後續版本變化	2.0 測試版增加擴展等功能	測試版功能不等於穩定版 1.x 已具備

Pelican 的功能描述來自其官方對比。該頁面由 Pelican 編寫，可用於確認文件列出的功能，不能作為速度優勢的獨立證據。

Pelican：優勢與取捨

如果團隊需要其管理權限模型和官方支援的外掛機制，Pelican 很有吸引力。這些功能可以減少維護核心檔案補丁的需求。

相應的代價，是圍繞具體版本、外掛和自動化進行驗證。外掛可以安裝，不代表它與計費系統、權限設定或下次升級兼容。Pelican 的外掛文件解釋了版本約束，並區分受支援的外掛接口與可能變化的內部實現。

我們的評價： 如果新部署有時間進行預覽測試，這是值得考慮的選擇。先測試具體版本，再根據管理流程能否幫助團隊決定是否採用。

Pterodactyl：優勢與取捨

如果現有 egg、員工操作流程和自動開通整合都正常執行，Pterodactyl 1.x 是實用的比較基準。保留已經驗證有效的依賴關係，可能比更換儀錶盤更有價值。

需要權衡的是：何時繼續投入現有修改，何時為 2.0 做準備。不要假設 1.x 的客製化能直接用於測試版，也不要認為 1.x 內部更新步驟能夠安全升級到 2.0。1.x 更新指南明確區分了這兩種流程。

我們的評價： 除非另一款面板能解決具體維運問題，否則保留健康、及時打補丁的安裝。將 2.0 測試視為獨立遷移項目。

效能：究竟會改變什麼？

面板品牌只是一個變量。以下四個層面值得分別測量：

層面	有用的指標	常見問題來源
Panel HTTP 請求	回應時間中位數/p95、錯誤率	PHP 工作程序、資料庫延遲、快取、反向代理
管理操作	控制台連接、安裝完成、備份完成	Wings 連通性、隊列、映像檔拉取、儲存
遊戲程序	tick/幀耗時、伺服器 CPU、記憶體、玩家可見卡頓	模組、腳本、世界大小、CPU 排程
VPS 主機與網路	CPU steal、I/O 延遲、丟包、路由	共用主機資源爭用、儲存飽和、路由不佳

更好的面板體驗，可能來自管理步驟減少，而不是遊戲模擬速度提升。反過來，無論使用哪款介面啟動備份，同一台 VPS 上的備份都可能與遊戲爭用 CPU 和磁碟。

Docker 限制同樣重要。CPU 配額限制的是消耗量，並非預留物理處理器容量。設定記憶體上限的容器，也需要為執行環境及原生記憶體分配留出餘量。參見 Docker 資源限制。

可重現的 A/B 測試

使用備用節點或隔離的預覽環境。保持遊戲二進位檔案、世界、執行環境、映像摘要、資源限制和玩家負載相同。記錄每個項目的 Panel 和 Wings 版本。盡可能匹配設定，並記錄兩種 Wings 實現之間的差異。

每次執行前，還原同一份世界備份。
以固排程長預熱遊戲及快取。
執行至少 30 分鐘具有代表性的遊戲會話。
分別測量面板空閒、活躍管理操作和排程備份三個階段。
每種設定至少重複三次，並交替測試順序。
比較分布和異常值，而不是選取一個方便的平均值。

在同一台 VPS 上順序測試，可以減少硬件差異，但共用主機的環境仍可能變化。在兩個節點上同時測試，則會引入主機之間的差異。無論採用哪種方法，都應記錄局限。

在 Ubuntu 測試節點上安裝診斷工具並檢查環境：

sudo apt update
sudo apt install -y sysstat
uname -m
systemd-detect-virt
lscpu
free -h
df -h
sudo docker version
sudo docker info --format 'Driver={{.Driver}} Cgroup={{.CgroupVersion}}'

在遊戲會話期間採集主機活動：

mkdir -p "$HOME/panel-ab-results"
mpstat -P ALL 1 60 > "$HOME/panel-ab-results/cpu.txt"
iostat -xz 1 60 > "$HOME/panel-ab-results/disk.txt"
sudo docker stats --no-stream

上述兩個排程命令是順序執行的。如需採集同一時段，請在不同終端執行，或在各階段重複執行。docker stats --no-stream 只提供快照；要獲得完整時間序列，應反復採樣或使用監控系統。

如需簡單採樣公開頁面的回應，替換主機名稱，並為兩款面板使用相同端點：

PANEL_URL='https://panel.example.com/'
for sample in $(seq 1 30); do
  curl --fail --silent --show-error --output /dev/null \
    --connect-timeout 5 --max-time 15 \
    --write-out '%{http_code},%{time_starttransfer},%{time_total}\n' \
    "$PANEL_URL"
done

這測量的是未驗證 HTTP 請求，包含網路和 TLS 的影響，並不測量登錄後的儀錶盤、併發使用者或遊戲延遲。針對這些情況，應使用受控的驗證負載和遊戲專用遙測。

如何如實報告結果

指標	Pelican 測試	Pterodactyl 測試	解讀方式
Panel HTTP p95	記錄實測值	記錄實測值	路由、客戶端、端點和請求次數相同
遊戲 tick/幀 p95	記錄實測值	記錄實測值	存檔、執行環境和負載相同
空閒時整個技術堆疊的記憶體	記錄實測值	記錄實測值	包含的服務和測量方式相同
備份耗時	記錄實測值	記錄實測值	資料、壓縮方式和目標相同
主機 CPU steal	記錄實測值	記錄實測值	檢查主機爭用是否干擾結果

這些是供你填寫的結果字段，不是本文的實測資料。缺乏這種控制時，“某款面板快 30%”之類的說法，不是有用的選購證據。

VPS 規格需求：分別規劃遊戲和面板

不存在一個記憶體要求，能夠同時代表空白儀錶盤和重度模組遊戲節點。以下是規劃建議，不是上游最低要求，也不是玩家數量保證。

部署方式	建議 CPU 起點	VPS 總記憶體	儲存規劃	說明
僅面板，小型社群	2 vCPU	2–4 GB	25–40 GB SSD	為 Web 技術堆疊及配套服務留空間；需驗證負載
面板 + 一個輕量遊戲	2–4 個高效能 vCPU	8 GB	80–100 GB SSD/NVMe	計入系統、容器、資料庫、更新和存檔
面板 + 重負載遊戲或多個小執行個體	4–8 個高效能 vCPU	16–32 GB 或以上	160–300 GB 或以上	按遊戲設定限制；測試持續 CPU 和儲存效能
獨立面板與多個節點	每台機器獨立規劃	按角色規劃	各節點資料及異機備份	遊戲節點靠近玩家；保證 Panel–Wings 安全連通

8 GB 主機不應把全部 8 GB 分配給遊戲。例如，假設遊戲上限為 5 GB，系統和管理技術堆疊佔 2 GB，就剩下 1 GB 工作餘量。實際技術堆疊可能需要更多，尤其是在安裝、壓縮和更新期間。

對於 Java 伺服器，堆只是容器記憶體使用的一部分。原生記憶體、執行緒堆疊和其他 JVM 額外負擔都計入容器上限。兩個容器各自設定為使用主機的全部記憶體，並不會產生更多記憶體。

軟體要求取決於具體版本

組件	需要覈實的要求
Pelican 目前安裝文件	PHP 8.4 或 8.5，推薦 8.5；所需擴展和支援的 Web 伺服器
Pelican 資料庫	滿足庫版本要求時支援 SQLite；文件中的外部資料庫包括 MySQL 8.4+、MariaDB 10.11+ 和 PostgreSQL 17+
Pterodactyl 1.x 安裝文件	PHP 8.2 或 8.3，推薦 8.3；MySQL/MariaDB 及文件中的 Web/隊列/快取組件
Pterodactyl 2.0 測試版文件	PHP 8.3 或 8.4、Composer 2、Redis，以及文件要求的 MySQL/MariaDB 版本
Wings 節點	能正常執行 Docker 的 Linux；Wings、映像檔和遊戲二進位檔案的架構需匹配

來源：Pelican 安裝要求、Pterodactyl 1.x 安裝、Pterodactyl 2.0 要求及 Pelican Wings 安裝。

文件的進度可能領先於固定使用的建置版本。遵循實際部署版本的依賴要求；上表不意味著可以盲目升級正式環境的 PHP 執行環境。Ubuntu 24.04 LTS 是合理的通用起點，但其預設軟體包並不自動滿足 Pelican 目前的全部要求。

希望順利部署 Docker 節點時，優先考慮 Linux KVM VPS。 基於容器的 VPS 虛擬化，在主機啓用必要內核功能後也可能可用，但需要確認。ARM64 版本的 Wings 也不能讓僅支援 x86 的遊戲程序在 ARM 上原生執行。

網路與安全：常見故障點

將以下服務分別規劃，並設定各自的存取規則：

服務	常見存取方案
Panel HTTPS	對管理員/使用者開放 TCP 443；僅在重定向或證書驗證需要時使用 TCP 80
Wings API 和控制台	使用設定的常駐程式連接埠和 TLS；允許 Panel 和瀏覽器所需的網路路徑
Wings SFTP	設定的 SFTP 連接埠，通常為 TCP 2022；按使用者需求限制
遊戲連接埠分配	開放各遊戲實際分配的 TCP 和/或 UDP 連接埠
Panel 資料庫和 Redis	使用本機/私有網路；避免公用網路暴露

在未確認瀏覽器如何存取控制台和檔案傳輸端點前，不要只允許 Panel IP 存取 Wings。Panel 登錄正常，不代表瀏覽器能連接 Wings。

Docker 發佈的連接埠與主機防火牆規則之間，可能產生非預期的交互。應從外部網路驗證開放範圍，並遵循適用於所用後端的 Docker 防火牆說明。單憑看似嚴格的 UFW 規則，不足以證明容器發佈連接埠已被阻斷。來源：Docker 資料包過濾與防火牆。

使用可信映像檔和審核過的 egg，維護主機，限制特權存取，並測試證書續期。容器隔離可降低部分風險，但不能保證主機不被攻破。網路 DDoS 防護屬於供應商和網路層面的選擇，而不是面板功能。

適合 Pelican 或 Pterodactyl 的五家 VPS 供應商

這些供應商供應面板底層的基礎設施，並不是 Pelican 或 Pterodactyl 的不同版本。遊戲安裝按鈕也不能證明預裝了任意一款面板。

供應商	適用場景	部署方式	主要比較點
LightNode — 綜合推薦	靈活選擇區域、短週期評估	在 Linux KVM 上自行部署任一面板	區域、所選規格、按小時/按月計費
Hostinger	希望簡化 Pterodactyl Panel 初始安裝	Pterodactyl 模板；Wings 單獨安裝	首期、續費、模板包含範圍
Hetzner	選擇共用或專用 CPU	自行安裝任一面板	持續 CPU 需求、架構、區域
Vultr	比較計算等級	自行安裝任一面板	具體等級、資源分配、完整報價
DigitalOcean	開發團隊主導維運	在 Linux Droplet 上自行安裝任一面板	CPU 系列及配套基礎設施成本

比較同等 CPU 分配、記憶體、磁碟、流量、位址費用、備份儲存和續費條件。最便宜的廣告 VM，不能等同於已為遊戲負載配足資源的節點。

1. LightNode — 靈活遊戲基礎設施的綜合首選

LightNode 的遊戲伺服器產品介紹了 KVM VPS 基礎設施、NVMe 儲存、超過 40 個全球區域，以及按小時/按月計費。還為已上線的遊戲提供一鍵安裝。

特徵： Linux VPS 基礎、區域部署、NVMe 儲存、靈活計費和遊戲安裝目錄。本文按自行管理的 Panel/Wings 部署方案評估；遊戲目錄不代表確認預裝了 Pelican 或 Pterodactyl 技術堆疊。

優點

可選擇區域，讓節點更適合社群的地理分布。
按小時計費適合預覽或對比測試階段。
基礎設施模式適合自行掌控技術堆疊。

缺點

下單前，需要查詢所選區域和設定是否處於售罄狀態。

我們的建議： 如果希望在長期部署前測試鄰近區域，可優先考慮。這是適用性判斷，不是實測效能勝出的結論。

前往 LightNode 遊戲伺服器代管。

2. Hostinger — 適合使用 Pterodactyl Panel 模板

Hostinger 提供包含 Panel、MariaDB 和 Redis 的 Pterodactyl 應用部署。產品頁明確說明，Wings 需要在遊戲節點上單獨安裝。

特徵： KVM VPS、NVMe 儲存、Pterodactyl 模板及每周基礎設施備份。

優點

減少 Panel 端的初始工作。
資源等級清晰，便於比較更高設定。

缺點

模板沒有完成遊戲節點安裝。
廣告中的月均價格需要預付款，續費價格不同。
Pterodactyl 模板不代表包含 Pelican。

我們的建議： 當初始面板架設比短期基礎設施測試更重要時，可考慮它。覈實安裝的軟體版本，並完成 Wings 設定。

前往 Hostinger Pterodactyl 代管。

3. Hetzner — 適合評估專用 vCPU 方案

Hetzner Cloud 區分共用資源和專用 vCPU 套餐，並提供私有網路、防火牆和 API，使 CPU 分配成為明確的選型因素。

特徵： 共用/專用 vCPU 等級、Linux 基礎設施、私有網路和自動化工具。

優點

可針對波動負載或持續 CPU 負載選擇。
網路工具有助於分離 Panel 和遊戲節點。

缺點

共用 CPU 套餐仍需進行繁忙時段測試。
架構、區域可用性、位址和備份會影響比較。

我們的建議： 如果已觀察到主機資源爭用瓶頸，可比較其專用 vCPU 報價。選套餐前檢查遊戲映像檔架構。

前往 Hetzner Cloud。

4. Vultr — 適合比較不同計算等級

Vultr 提供多個計算類別，包括通用型和注重效能的選項。管理員可評估不同執行個體類型，用於自行安裝的技術堆疊。

特徵： 多種計算等級、Linux 執行個體，以及文件中的映像檔/備份部署選項。

優點

不局限於單一入門 VM 系列進行比較。
適合乾淨地手動安裝任一面板。

缺點

注重效能的產品命名，本身不能證明專用 CPU 分配。
需要分別比較流量額度和附加服務。

我們的建議： 測試實際選擇的等級，包含備份階段。產品標籤本身無法預測遊戲 tick 延遲。

前往 Vultr · 查看 Cloud Compute。

5. DigitalOcean — 適合自行建置工具的團隊

DigitalOcean Droplet 是 Linux 虛擬機器，提供共用及專用 vCPU。適合希望同時維護面板及自有基礎設施自動化的團隊。

特徵： 多個 Droplet 系列、Linux/自訂映像檔和配套雲服務。

優點

CPU 分配選項可適應不同負載階段。
基礎設施生態適合開發團隊主導的維運。

缺點

廣告中的小型入門套餐，不適合作為面板與遊戲節點合用的預算。
備份和出站流量需求可能提高總成本。

我們的建議： 如果團隊已使用其工具，可納入比較。先為遊戲規劃資源，再計算完整維運帳單。

前往 DigitalOcean Droplets。

從 Pterodactyl 遷移到 Pelican

將遷移視為資料變更，而不是安裝主題。Pelican 的官方遷移指南介紹了原地升級資料庫，並提醒該操作不能簡單撤銷。文件要求以 Pterodactyl 1.11.4 或更新版本為起點，同時滿足 Pelican 目前的依賴條件。

操作前：

在隔離副本上演練，阻止正式環境代理和自動化連接該環境。
保存 Panel 資料庫、.env 與加密金鑰、Wings 設定、遊戲檔案及異機備份。
清點 egg、主題、修改、API 客戶端、排程任務和計費整合。
遵循目前上游流程，包括每個節點的 Wings 切換。
測試登錄、控制台、SFTP、電源操作、計劃任務、備份建立/還原和自動開通。
如需回復舊版，同時還原遷移前資料庫及對應軟體/設定。

指南說明主題和面板修改不會隨遷移保留，舊的 nests/locations 端點也會變化。保留 API 金鑰，不保證每個腳本都繼續正常工作。不要讓兩個面板同時作為寫入端連接同一遷移後的資料庫。

應該選擇哪一款？

情況	建議方向
正常工作的 Pterodactyl 1.x 生產安裝	保持補丁更新；僅為解決具體問題而遷移
新社群看重 Pelican 外掛和員工角色	在預覽環境評估，覈實發行狀態和具體整合
對 Pterodactyl 2.0 功能感興趣	遵循上游正式環境建議，在測試面板執行測試版
兩種介面下遊戲效能都不佳	換面板前分析遊戲和主機
玩家遠離節點	重新評估節點位置和路由
管理時間有限	比較預安裝和持續支援的實際範圍

當區域和計費方式適合項目時，我們優先考慮 LightNode。圍繞玩家選擇節點，測試真實負載，並查詢所選設定的庫存。隨後再根據所需管理功能和整合決定面板。

查看 LightNode 遊戲伺服器代管。