小編精選 - 技術文章翻譯 · 08月11日

當你的 VPS 從來就沒有被賣給你的那些資源

我需要一台 VPS 來跑 CyberPanel。需求很簡單：1 顆 vCPU、1 GB RAM、10 GB SSD、僅 IPv6。CyberPanel 需要 IPv4，所以我升級到下一個方案：2 顆 vCPU、2 GB RAM、20 GB SSD，外加一個 IPv4 位址。

接下來，在同一家供應商、同一台主機、24 小時內發生了兩起彼此獨立的基礎架構故障。兩者都不是 Linux 問題，而是佈建問題——也就是方案承諾與實際掛載到虛擬機上的資源之間的落差。

我不會點名供應商。這是一家法國的小型主機商；這篇文章的重點不是替他們導流，而是這種現象本身。在 VPS 世界裡，這種模式其實相當常見，值得好好記錄。

問題 1：消失無蹤的 IPv4

升級完成後，新的 IPv4 位址出現在控制面板裡。介面已啟動、IP 已設定、預設路由也存在，對閘道的 ARP 解析也正常：

88.151.197.1 lladdr 44:4c:a8:fb:ef:fd REACHABLE

但 ICMP 完全沒有回應，不論是 VPS 本身，還是閘道本身都一樣：

88.151.197.112 > 88.151.197.1: ICMP echo request
(no reply)

整個過程中 IPv6 都正常運作。來賓端的所有設定——介面、路由、ARP——都是正確的。這本身就是很有用的診斷訊號：當 ARP 已經解析成功，但 ICMP 卻毫無回應時，代表來賓作業系統該做的都做了，問題在更上層的基礎架構層——通常是 hypervisor 或虛擬交換器上的 MAC/IP 綁定沒有更新成新的位址。

最後問題確實解決了，但對方沒有說明到底改了什麼。到那時，我已經因為一台在紙面上從第一分鐘起就設定正確的主機，白白耗掉了大半天處理連線問題。

問題 2：從來就不存在的磁碟

IPv4 終於正常後，我開始安裝 CyberPanel——這次升級的全部目的。全新安裝 Ubuntu 一切順利，直到 CyberPanel 的相依套件安裝開始拋出 No space left on device。於是我檢查了一下：

root@panel:~# lsblk
NAME    MAJ:MIN RM SIZE RO TYPE MOUNTPOINTS
sda       8:0    0  3.5G  0 disk
├─sda1    8:1    0  2.5G  0 part /
├─sda14   8:14   0    4M  0 part
├─sda15   8:15   0  106M  0 part /boot/efi
└─sda16 259:0    0  913M  0 part /boot

磁碟只有 3.5 GB。根分割區只有 2.5 GB。方案承諾升級後應該有 20 GB——而事後看來，原本的 10 GB 方案其實也從未真正提供超過其中一小部分。這不是升級造成的副作用；問題從一開始就存在，只是升級把目標從 10 GB 提到 20 GB，而實際配置完全沒有變。

很多教學在這裡會叫你用 growpart 或 resize2fs。在這個情況下它們都沒用，而理解原因很重要：

layers diagram

resize2fs 和 growpart 是作用在最底下兩層的工具。它們只能把檔案系統或分割區延伸到虛擬磁碟上已經存在的空間。如果磁碟本身只有 3.5 GB，那就根本沒有可延伸的未配置空間——工具會回報成功，或者什麼都不做，因為它們真的沒事可做。問題不在來賓作業系統，而是在更下層，也就是 hypervisor 實際掛給 VM 的資源。

我開了支援單，附上 lsblk 的輸出，請他們檢查磁碟掛載狀況。

對方回覆把磁碟不足歸因於「IPv6 轉 IPv4 升級」——彷彿配置一個新的 IPv4 位址可以把虛擬磁碟縮小一樣。這當然不會，而且在上圖所示的每一層，兩者都毫無關聯。這讀起來與其說是診斷，不如說是把第二個尚未解決的工單，方便地塞進第一個裡面。

問題 3：「修好了」不代表真的修好

供應商的做法是要我再檢查一次——他們自己沒有做任何診斷。我照做，這次磁碟正確了：20 GB，符合訂單。我回覆「已修正，謝謝」，工單就結案了。

但同一天晚些時候，我為了建立乾淨的基準再次重灌 Ubuntu。結果磁碟又錯了——跟修好之前一樣，不是修好之後的狀態：

root@panel:~# date
Mon Aug  3 20:56:49 UTC 2026
root@panel:~# lsblk
NAME    MAJ:MIN RM SIZE RO TYPE MOUNTPOINTS
sda       8:0    0  3.5G  0 disk
├─sda1    8:1    0  2.5G  0 part /
├─sda14   8:14   0    4M  0 part
├─sda15   8:15   0  106M  0 part /boot/efi
└─sda16 259:0    0  913M  0 part /boot
sr0      11:0    1    4M  0 rom

同樣是 3.5 GB 的磁碟、同樣是 2.5 GB 的根分割區，而且是在工單標記為已解決好幾個小時之後。

這正是值得停下來思考的地方。透過支援單對一台正在運作的主機做的「修正」，不一定真的碰到了出問題的那個東西。如果底層 VM 設定檔或佈建範本有問題，支援人員可以手動把當下的磁碟配置補正，然後宣稱已結案——但下一次重建又會從同一個壞掉的範本取值，重現完全相同的故障。這個修正只是修好了某一台實例，而不是修掉根因。

實務上的教訓是：如果某個資源佈建問題在一台正在運作的 VPS 上被「修正」了，不要急著收工，先確認它在重建之後仍然正常。一次性的手動修補和已修正的範本，從支援工單上看起來是一樣的；但從 lsblk 看起來，完全不一樣。

一天內發生兩次故障，代表什麼

單獨看，這兩個問題都可能被當成偶發故障。放在一起看，訊息就很明確了：同一台實例、同一個升級週期內，出現兩個彼此獨立的佈建不符——磁碟和網路——其中一個還在被標記為已修復後再次出現。這種模式指向的是佈建管線本身，而不是單純的運氣不好。

值得記住的指令

如果你遇到類似情況，下面這些指令可以幫你判斷自己到底碰到哪一層的問題：

lsblk                           # Linux 看到掛載了什麼
fdisk -l                        # 分割表細節
df -h                           # 檔案系統使用量
blockdev --getsize64 /dev/sda   # 原始裝置大小，單位為位元組
ip addr                         # 介面與 IP 狀態
ip route                        # 路由表
ip neigh                        # ARP/NDP 快取 — 閘道可達性
ping -c 3 <gateway>             # 基本連通性測試

如果 lsblk 和 blockdev --getsize64 顯示的磁碟本來就比你付費的規格小，就不要去碰 growpart 或 resize2fs——你遇到的不是 Linux 問題。
如果 ip neigh 顯示閘道是 REACHABLE，但 ping 完全沒回應，那也不是 Linux 問題。在這兩種情況下，修正都在 hypervisor 邊界的另一側；不管你怎麼從來賓端排查，都碰不到真正的問題。

結論

VPS 不是實體硬體，但它仍然應該遵守同樣的基本契約：廣告上的資源，必須就是實際提供的資源。在怪罪 Linux、某個套件，或你自己的設定之前，先檢查更下層；而且如果供應商告訴你問題已經修好了，先驗證它在重建後仍然正常，再相信他們。

這一切並不需要什麼特別深入的挖掘——lsblk、ip neigh、再重建一次確認而已。這其實才是重點：以差不多的價格，甚至更便宜的價格，像 OVH、Contabo 或 Infomaniak 這類供應商提供的配置，往往不需要你為了拿到自己付費的資源就做這種鑑識般的排查。追求最低標價是有代價的，只是這個代價不一定馬上看得見，往往要等你已經白白浪費了一天才會發現。

原文出處：https://dev.to/pascal_cescato_692b7a8a20/when-your-vps-never-had-the-resources-it-was-sold-with-302o