丟包或 ping 值過高

我們希望您真正喜歡使用我們的伺服器並享受我們的服務。 然而，透過 Internet 進行的通訊始終受到許多影響連接的因素的影響。 因此，可能會出現一些問題，為了調查和解決它，我們需要了解哪個端導致了問題。

因此，如果您 p​​ing 伺服器並且某些資料包遺失，或者需要很長時間才能收到回應（超過 110 毫秒），則表示存在網路問題。

請注意，本文適用於儘管存在網路問題但伺服器仍可用的使用者。 如果伺服器完全沒有回傳任何資料包，請參閱我們的指南以了解伺服器不回應 ping 的情況。

案例

1. 如果您使用代理或 VPN，請將其停用並再次 ping 伺服器。 如果有幫助，則問題是由中間伺服器引起的。 您可以繼續連接而不使用它，或考慮更改 VPN/代理。

2. 如果您最近更改了網路設置，請恢復先前的設定並再次嘗試 ping 伺服器。 如果有幫助，則表示問題是由網路配置引起的，您應該考慮是否繼續使用舊配置還是編輯網路設定。

若要將網路設定自動重設為預設參數，您可以重新安裝伺服器作業系統。 請注意，重新安裝作業系統將導致伺服器上的所有資料遺失。

若要重新安裝作業系統，您可以使用以下指南之一：

https://gcore.com/docs/hosting/virtual-servers/manage/operating-system/install-a-linux-os-from-a-template
https://gcore.com/docs/hosting/virtual-servers/manage/operating-system/install-an-os-from-a-template-in-vmmanager-6
https://gcore.com/docs/hosting/dedicated-servers/manage/operating-system/install-a-linux-os-from-a-template

3. 如果上述步驟不適合您，或沒有協助，請聯絡我們的技術支援。 請在您的請求中提供以下資訊：

• 您是否正在使用 VPN/代理以及您最近是否更改了網路設定。 如果是這樣，請說明停用 VPN/代理或恢復到舊設定是否有幫助。
• 您的伺服器的 IP 位址。
• 與伺服器連接不良的 IP 位址。
• 您所在的國家和城市。 如果您是經銷商並且您的客戶遇到網路問題，請指定您的客戶所在的國家/地區和城市。
• 問題發生時的日期和時間（UTC+0）。
• 從客戶端到伺服器的 ping 和tracert（Windows）/ping 和traceroute（Linux）/mtr（UNIX 系統）的輸出。
• 從伺服器到客戶端的 ping 和tracert（Windows）/ping 和traceroute（Linux）/mtr（UNIX 系統）的輸出。

上述所有資訊中最重要的資訊是地鐵輸出。 我們還有一篇關於如何運行 mtr 的文章，以防您需要：

https://support.gcore.com/hc/zh-cn/articles/19864311353105-如何在-Windows-和-Linux-上运行-MTR

但為什麼它對於分析網路問題如此重要？ 之所以如此，是因為它使我們能夠了解導致問題的原因。

讓我們來看一些範例，看看它有何幫助。

因此，我們在 Gcore 的 Hosting 購買了一台虛擬專用伺服器，IP 為 185.105.3.226，這是第一種情況：

在檢查 mtr 輸出時，首先應該注意 Loss% 列，它在上面的螢幕截圖中進行了標記。

所以，在這裡我們可以看到伺服器的IP上發生了丟包，但更重要的是丟包是從哪裡開始發生的。 在本例中，它們首先出現在第三跳，IP 為 184.185.64.201，屬於名為 Hurricane Electric LLC 的 ISP。 由於問題是從他們的網路開始的，因此此躍點之後顯示的所有損失都只是繼承它，您需要聯繫他們才能解決問題。

附： 為了接收任何 IP 背後的 ISP 訊息，您可以使用 whois 命令列範例（您需要安裝它）或基於它的任何第三方服務。 這是它在終端機中的樣子：

為了進行比較，這是我們的伺服器 IP 185.105.3.226 的另一個例子：

乍一看，我們在這裡看到了同樣的情況：伺服器的 IP 上發生了丟包。 但它起源於這裡的不同面向。 它從第一跳開始（在您的情況下，它將是您的 IP/您客戶端的 IP），然後封包遺失也會傳播到路徑上的下一個主機。 在我們的範例中，應聯絡名為 Bamboozle Web Services Inc. 的 ISP 並要求解決方案。 對於您的情況，應檢查來源（用於連接向我們購買的伺服器的電腦），或應聯絡您當地的 ISP 以解決問題。

這是同一台伺服器的第三種情況：

在這種情況下，我們仍然看到 Gcore 側出現丟包，但這裡第一次沒有出現之前的丟包情況。 類似的結果意味著問題源自於我們的設備，您需要聯絡我們才能解決問題。

然而，對我們來說至關重要的是獲得反向 mtr（反之亦然 - 不是從您/您的客戶端到伺服器，而是從伺服器到您/您的客戶端）。 伺服器.

所有上述數據將有助於我們更詳細地評估情況，並加快對問題根源的調查。