Amsterdam VPS Hosting 怎麼選才不踩雷

為何選擇 Amsterdam 的 VPS hosting

在 Amsterdam 使用 VPS hosting，首先是網路層面的決策。Amsterdam 是歐洲主要的網路互連據點之一，大量獨立網路在此互連，並直接彼此交換網路流量。位於該都會區的伺服器，通常可透過較短的路徑連線至英國、北歐、德國、法國與 Benelux 國家，中間經過的網路數量也較少。

這就是主要理由。本指南其餘內容將協助你確認這項理由是否適用於你的使用者，因為它並非適用於所有人。若客戶群分布在西北歐，Amsterdam 是很好的預設選擇。若大多數網路流量來自 Warsaw、Istanbul、São Paulo 或 Toronto，則不適合選擇 Amsterdam，因為荷蘭的良好對等互連並不會縮短前往這些地點的距離。

實際上的 Internet Exchange 是什麼

Internet Exchange Point（或 IXP）是共用的交換網路。各個獨立網路在其上租用連接埠，接入一次後，就能直接與其他成員交換網路流量。阿姆斯特丹最知名的 Internet Exchange 是 AMS-IX，也就是 Amsterdam Internet Exchange。但該城市不只有這一個 Exchange，而 Exchange 的數量對你並不重要。

若要了解 Exchange 為何會改變延遲，必須先了解封包在網路之間傳遞的兩種方式。第一種是 Transit：你付費給較大型的網路，由它將你的流量傳送到 Internet 的其他部分。第二種是 Peering：兩個網路同意直接相互傳遞流量，通常雙方都不需要付款。這裡的每個網路都是 Autonomous System，或 AS，也就是擁有專屬編號與路由政策的網路。

Transit 路徑的選擇不只取決於地理位置，也取決於商業關係。從某個歐洲城市的伺服器傳送到另一個城市的寬頻客戶端時，封包可能合理地先經過第三個城市，在那裡切換網路後再傳回來。這不代表系統故障。該路由只是由付款關係與路由政策決定。在 Exchange 中，兩個網路可以改在本地交接封包，因此路徑較短、涉及的網路較少，也減少了可能發生壅塞的位置。

以下是容易被略過的重點。城市中的 Exchange 不會讓你的 VPS 自動接入該 Exchange。真正重要的是供應商自己的網路：它向哪些 Transit Provider 購買服務、加入哪些 Exchange、是否與使用者所連接的固網與行動網路進行 Peering，以及與這些網路之間具備多少容量。同一棟建築內的兩台伺服器，對外可能有非常不同的路徑。請向供應商索取其 AS 編號，再到 PeeringDB 查詢。各網路會在該網站公布其所在的機房與 Exchange。你也可以直接從即時路徑讀取 AS 編號；下方的測量章節會示範這項操作。

Amsterdam 或 Frankfurt：依據使用者所在地決定，不要只看地圖

這是多數讀者真正面對的選擇，而這兩座城市都是重要的互連節點。Frankfurt 設有 DE-CIX，通常適合中歐、東歐與東南歐，以及通往 Vienna、Warsaw、Prague 和中東的網路路徑。Amsterdam 則適合 United Kingdom、Ireland、Scandinavia 和 Benelux，也適合使用西北歐海底電纜登陸點的網路流量。請將這些視為趨勢，而不是測量結果。路由會變更，供應商會更換上游，而你的供應商所採用的對等互連，比任何以城市為單位的概括更具體。

因此，請使用自己的資料做決定。

1. 記錄使用者實際所在的位置。Web server access logs、分析資料或客戶名單通常已包含這些資訊。
2. 依據營收或活躍帳戶等重要指標為這份清單加權，不要只使用會被機器人灌高的原始命中次數。
3. 在每個候選城市租用最小方案 1 個月，並從實際使用者連線測量到兩個城市的結果。
4. 比較你收集的數據，不要比較行銷頁面上的數字。

在你花 1 週處理這件事之前，先說明一項務實的限制。對於位於西歐的使用者群組，兩個連線品質良好的歐洲大都會之間的差異，通常小於應用程式本身增加的延遲。一個依序執行 10 次資料庫查詢的頁面，會支付 10 次往返延遲，因此查詢模式造成的成本可能高於城市選擇。也請測量應用程式本身。從另一端提出的相同問題，請參閱選擇 Frankfurt VPS 的指南；最後的決定因素往往很普通，例如哪個地點提供你需要的方案大小與磁碟空間。

自行測量到 Amsterdam 的延遲

請從使用者實際使用的連線執行這些指令，或盡量在接近該連線的位置執行。Manchester 的行動網路連線，不能用辦公室光纖代替。

在 Debian 或 Ubuntu 上，請先安裝工具。

sudo apt update && sudo apt install -y mtr-tiny traceroute curl

先測量多次往返。

ping -c 20 ams.example.com

結尾的摘要標示為 rtt min/avg/max/mdev。avg 是以毫秒表示的典型往返時間，mdev 是往返時間的變動幅度，也就是 jitter。請在同一區塊讀取封包遺失百分比。目的地發生封包遺失是真正的問題。若只有某個中間 hop 回報封包遺失，而後續每個 hop 的數值都正常，通常不代表問題，因為路由器會降低對於送往自身封包之回覆的優先順序。

接著查看實際路徑。

mtr --report --report-wide --show-ips --aslookup --report-cycles 100 ams.example.com

每一行代表一個 hop，--aslookup 會列出 AS number，因此可以看出封包通過哪些網路，以及在哪裡離開供應商的網路。請找出往返時間開始升高，且在後續每個 hop 都維持高值的 hop；延遲就是在該處增加的。如果 mtr 因為無法開啟 raw socket 而結束，請使用 sudo 執行。部分網路會降低 ICMP 的優先順序或丟棄 ICMP，因此也要按照使用者的連線方式測量，透過 TCP 連到服務使用的連接埠。

sudo mtr --tcp --port 443 --report --report-cycles 100 ams.example.com

接著將網路延遲與伺服器延遲分開。

curl -o /dev/null -s -w 'dns %{time_namelookup}\nconnect %{time_connect}\ntls %{time_appconnect}\nttfb %{time_starttransfer}\ntotal %{time_total}\n' https://ams.example.com/

每個數值都是從請求開始後經過的秒數，因此要讀取的是數值之間的差距。connect 減去 dns 大致是一次往返時間，也就是 TCP handshake。tls 減去 connect 是 TLS (transport layer security) handshake，需要更多次往返，因此距離越遠，這段時間增加得比該行其他部分更快。ttfb 減去 tls 主要是伺服器處理請求所花的時間。這種拆分方式也是 curl 比 ping 更適合用來評估購買方案的原因。總時間很長，但 ttfb 的差距很小，表示伺服器距離遠。ttfb 的差距很大，但連線建立很快，表示伺服器距離近，而應用程式速度慢。

延遲也會隨時間變化，因為網路壅塞程度會變化。請在一天內分時段取樣，不要只根據一次測試判斷。

while true; do date -Is; ping -c 10 -q ams.example.com | tail -2; sleep 300; done | tee latency.log

網路只是採購評估的一半。磁碟與 CPU 是另一半；即使伺服器位置理想，若位於超額訂閱的節點上，使用者仍會感覺速度緩慢。因此，承諾購買一年方案前，請先用試用方案執行 完善的 VPS 基準測試。

以白話說明 EU 資料留存地

資料留存地是資料儲存與處理的實體位置。荷蘭位於歐洲聯盟與歐洲經濟區，因此在 Amsterdam 的伺服器會讓資料留在 EU 基礎設施上。這只能解決位置問題，而位置只是合規問題的其中一項考量。

GDPR（一般資料保護規則）並未禁止個人資料離開 EU。它規定資料傳輸必須符合特定條件，也適用於代表你處理資料的其他公司。因此，有用的問題不是「伺服器是否位於 EU」，而是「這些資料的每一份副本最後會到哪裡」。

資料留存地聲明通常會在這裡失效。VPS 位於 Amsterdam，資料庫也在該伺服器上。接著，備份被傳送到其他區域的物件儲存，應用程式日誌串流至代管搜尋服務，錯誤追蹤資料傳送給監控廠商，交易郵件透過第三方寄出，使用者文字則提交至 API 進行摘要。每一項都會將個人資料移至某個位置。位置要求涵蓋所有這些處理，不只涵蓋你刻意選擇的那台機器。

請分開看待這兩種目的，因為它們會導向不同的設計。如果合約、主管機關或客戶要求使用 EU 基礎設施，這是合規要求，應明文記錄，且可能迫使你留在單一區域。如果你希望伺服器靠近使用者，讓頁面載入更快，這是延遲要求，可能需要增加區域。使用合規用語來合理化效能決策，日後將無法清楚回答其中任何一個問題。

請向供應商確認哪些人員可以存取機器、支援人員位於何處、該公司受哪個法域管轄，以及是否有任何子處理者位於 EEA 以外。請將答案載入資料處理協議，因為稽核人員要求的是已簽署的文件，而不是支援票證。完整方法請參考 針對加拿大資料撰寫的資料留存地框架，其原則可直接套用：列出資料、列出所有接觸資料的處理者、記錄必須符合的規則，最後才選擇位置。這是在說明應提出哪些問題，不是法律建議。

選擇 Amsterdam 無法解決的問題

• 與其他地點的距離。訊號在光纖中的傳輸速度約為真空光速的三分之二，而纜線路徑一定比直線距離長，因此無論選擇哪個歐洲城市，位於 Singapore 的使用者都必須承受這段距離造成的延遲。
• 頻繁往返的應用程式。每個必須等待前一個請求完成的請求，都會再次承受一次往返延遲。
• 單一區域的風險。在單一城市使用一台 VPS，就只有一個故障網域；即使 peering 良好，也無法避免誤刪錯誤的 volume。
• 超額配置的硬體。位於網路連線良好城市中的繁忙節點，仍然是繁忙節點。

如果使用者分布在不只一個洲

規則很簡單：將伺服器放在最接近使用者的據點。如果使用者分散在不同洲，放在中間位置反而會讓兩群使用者都感到緩慢，因為兩邊都不在附近。

實際上有兩種做法。將所有可快取的內容放在 CDN（content delivery network）後方，讓 origin 留在 Amsterdam，同時從鄰近各使用者的節點提供圖片、樣式表、指令碼與快取頁面。或者在另一個區域執行第二台伺服器，明確處理資料同步問題，例如使用 read replica，或使用已測量並記錄延遲的 replication。這兩種做法的成本都高於只使用一台伺服器。這就是使用者分散時必須付出的實際代價。

如果流量中有很大一部分來自 North America，位於 Toronto 的 VPS 會比任何 European city 更有效率地服務這些使用者；對 South America 的使用者而言，託管於 Brazil 的 VPS 可避免每次請求都經過一次跨大西洋往返。當使用者位於 Europe，且主要集中在北部與西部時，選擇 Amsterdam 是正確的。這是具體的判斷，而上面的命令可用來根據你自己的流量加以驗證。

FAQ

阿姆斯特丹的 VPS 會比法蘭克福的更快嗎？

對您的使用者而言，可能會。這兩個城市都是主要的網路互連節點，因此差異取決於使用者所在位置，以及各供應商與哪些網路建立對等互連，而不是城市名稱。阿姆斯特丹通常較適合英國、愛爾蘭、斯堪地那維亞與 Benelux；法蘭克福通常較適合中歐與東歐。先分別租用兩地最小的月租方案，再從實際使用者的連線執行 mtr --report --aslookup 和 curl -w 測試，持續一週後再決定。

在阿姆斯特丹託管服務，就符合 GDPR 嗎？

不會。這表示資料位於 EU 基礎架構上，但只回答了其中一個問題。合規性也涵蓋您的法律依據、資料處理者、備份、日誌，以及您傳送個人資料給的每個第三方服務。若位於阿姆斯特丹的伺服器將錯誤追蹤資料傳送給 EEA 以外的供應商，這些資料仍已被移出 EEA。位置是最容易處理的部分，也是許多人僅做到的部分。

AMS-IX 是什麼？它會影響我的 VPS 嗎？

AMS-IX 是 Amsterdam Internet Exchange，提供共用交換架構，讓獨立網路彼此直接連線並交換流量，而不必付費給 transit provider，讓對方在網路之間轉送流量。您的 VPS 只有在供應商連線至該交換中心時，才會受到它的影響。若您的供應商位於該交換中心，且與使用者所屬的網路建立對等互連，該城市的交換中心就能帶來幫助。請索取供應商的 AS number，並在 PeeringDB 查詢該編號與哪些網路建立對等互連。

支付一年的費用前，如何測試通往 VPS 的網路？

先購買最小的月租方案。執行 ping -c 20 測試往返時間與封包遺失，再執行 mtr --report --report-wide --aslookup --report-cycles 100 查看路徑經過哪些網路，接著針對實際頁面執行 curl -w 的 HTTPS 測試，以區分距離與伺服器速度的影響。請在不同時段重複測試，因為壅塞情況會隨一天中的時間變化；測試來源也應使用您的使用者所用的連線，而不只是辦公室的連線。保留日誌，這樣比較的是已記錄的數值，而不是主觀印象。