測速可以跑到好幾百 Mbps，為什麼 RDP 的輸入還是很慢？

搬運大量資料的速度，和操作後得到回應所需的時間，是兩回事。輸入的傳送、遠端應用程式的處理、畫面的壓縮、傳輸，以及本機的顯示都與此有關。此外，測速的對象和 RDP 的遠端之間，通訊路徑也不相同。

打字很正常，只有捲動時會卡頓，這是網路的問題嗎？

不能只歸咎於網路。畫面更新變多時，遠端的繪製與壓縮、通訊、本機的解碼與顯示，任何一個環節都可能跟不上。一次改變一項遠端的解析度或監視器數量來比較，必要時再調查與繪製相關的計數器。

ping 很快，就代表 RDP 的通訊正常嗎？

光憑這一點無法判斷。ping 測量的是對 ICMP 的回應，不會測量 RDP 的畫面傳輸或應用程式的處理。在使用 RD Gateway 等的組態中，路徑也可能不一致。沒有回應時，也請區分是 ICMP 遭到封鎖，還是 RDP 本身無法連線。

User Input Delay 是從按下按鍵到出現文字的時間嗎？

不是。它是一個計數器，測量的是在遠端輸入進入佇列之後、到處理程序把它取出為止的等待時間。它並不是涵蓋通訊往返、取出後的應用程式處理，以及畫面壓縮、解碼與顯示在內的體感延遲。

RDP 很卡時，應該停用 UDP 嗎？

不建議一律這麼做。先確認實際的連線方式、路徑與套用的原則。有時是因為無法使用 UDP 而退回 TCP，改成只用 TCP 也不一定每次都會變快。在管理員的許可下把條件統一後再比較，並把不必要的變更改回來。

網路很快，RDP 為什麼還是很卡？ ── 把輸入、繪製與通訊分開調查

2026年09月11日 02:00 · 更新日期: 2026年10月26日 · Go Komura · Windows, RDP, 遠端桌面, 效能, 疑難排解

測速可以跑到好幾百 Mbps，在遠端桌面裡打字，字卻要稍晚一點才出現。捲動圖片很多的網頁時，畫面會卡一下。只有在業務應用程式按下搜尋時，才會停住好幾秒。遇到這種「網路很快，RDP 卻很卡」的狀況，該從哪裡開始調查呢？

RDP 的操作回應，並不是只由網路的傳輸速率決定。即使測速很快，也可能在通訊往返、遠端應用程式的輸入等待、畫面的編碼、本機的解碼與顯示當中的某個環節發生等待。請先區分「哪一種操作慢」，再一次只改變一個條件，比較同一個操作。透過比較與測量縮小調查範圍，UDP 與 GPU 的設定則依照結果來選擇。參見：連線品質的測量區間、工作階段主機的效能因素。

不過，在縮小調查範圍的階段，根本原因還沒有確定。即使降低解析度後有所改善，改變的也不只是通訊，兩端的畫面處理也跟著改變，因此不會斷定「原因出在網路」。請把測量過的區間和沒有測量的區間分開，記錄結果。

本文要釐清的是連線之後的輸入、捲動與應用程式回應。即使症狀相似，原因也不一定只有一個。「登入畫面要很久才出現」「只卡在驗證」這類情況，屬於要從連線建立與驗證的記錄著手調查的另一種問題。

主要對象是從 Windows 的「遠端桌面連線」（mstsc）連線到 Windows 11 或 Windows Server 的使用者與管理員。命令範例以 Windows PowerShell 5.1 為準。前提是能在已連線的工作階段中重現同一個操作。

直接連線、VPN、RD Gateway 與 Azure Virtual Desktop 的路徑、可用的診斷資訊以及設定的套用對象都不相同。TCP 3389 的確認範例，僅限於經過許可、直接連線到使用標準連接埠的 RDP 主機。不要把 Azure Virtual Desktop 資料中的診斷功能或 GPU 設定，直接套用到一般的公司內部 PC。

在公司的裝置上，只在管理員許可的範圍內進行調查。在共用主機上，要辨識自己的工作階段與目標處理程序；如果需要其他使用者的記錄，請委託管理員。效能計數器是否可用、顯示名稱與所需權限，要依各自的環境確認。

這裡介紹的確認方法是根據官方資料，並不是在特定裝置上重現並解決故障的實測報告。數值範例會和用於說明的假設區分開來呈現。

想了解運作原理，可以從下一節「傳輸速率與往返時間」開始依序閱讀。如果要從症狀著手調查，請直接前往「依症狀選擇最初的比較」。操作步驟請見「逐一比較條件」與「測量等待發生的位置」。

圖中實線表示始終成立的關係，虛線表示附帶條件的關係（成立條件寫在詳細頁面中各關係的說明中）。關係的完整清單（共 7 條，附依據與可信度）以及主要概念的定義，彙整在知識地圖詳細頁面（日文）。資料：JSON-LD / Turtle

傳輸速率與往返時間

RDP（Remote Desktop Protocol）是在本機裝置與遠端之間交換輸入與畫面資訊等的通訊協定。它處理的不只是畫面和輸入，還包括裝置重新導向與列印等資訊。參見：RDP 傳輸的資訊。

網路的傳輸速率，表示 1 秒內可以搬運多少資料。測速結果的「500Mbps」就是關於這個量的數字，並不是表示從操作到收到回應需要多久的數字。參見：RDP 的頻寬需求。

flowchart TB
    accTitle: 測速數字代表的意義
    accDescr: 測速的 500Mbps 是表示 1 秒內可搬運資料量的數字，和從操作到收到回應的時間是不同的數字。
    A["測速：500Mbps"] --> B["1 秒內可搬運的資料量"]
    B -.->|"另一個數字"| C["收到回應所需的時間"]

圖1：測速的數字表示可搬運的量，不代表收到回應所需的時間。

往返時間（RTT）是指通訊抵達對方再回來所需的時間。提高傳輸速率和縮短往返時間的差別，就像增加道路的車道和縮短到目的地的距離之間的差別。即使搬運大量檔案的能力提升了，只要往返時間不變，等待操作回應的時間仍然存在。參見：RTT 與畫面顯示的延遲。

flowchart TB
    accTitle: 用道路比喻傳輸速率與往返時間
    accDescr: 把提高傳輸速率比喻為增加道路的車道，把縮短往返時間比喻為縮短到目的地的距離。
    A["提高傳輸速率"] -->|"換成道路"| B["增加車道"]
    B ~~~ C["縮短往返時間"]
    C -->|"換成道路"| D["縮短距離"]

圖2：就算增加車道，到目的地的距離也不會變短。

從輸入一個字到結果傳回

想像在遠端的記事本輸入一個字的情境。記事本是在遠端執行的。為了方便說明，假設操作送達需要 50 毫秒、結果的畫面資訊傳回需要 50 毫秒，那麼通訊所花的時間合計是 100 毫秒，也就是 0.1 秒。兩端的處理時間不包含在這個例子裡。

flowchart TB
    accTitle: 一個字的結果傳回前的通訊時間範例
    accDescr: 為了方便說明，假設去程與回程各 50 毫秒的例子。不包含兩端的處理時間，也不代表每次按鍵的封包數量。
    A["在本機輸入一個字"] -->|"去程：50 毫秒"| B["遠端收到輸入"]
    B --> C["傳送反映輸入的畫面"]
    C -->|"回程：50 毫秒"| D["結果送達本機"]

圖3：假設去程 50 毫秒、回程 50 毫秒，光是通訊就要 0.1 秒。這不是實測值。

即使網路可搬運的量增加了，只要往返時間不變，這 0.1 秒依然存在。圖3是用來理解處理流程的概念圖，並不是說每次按鍵都會送出一個獨立往返的封包。測速的對象和 RDP 的遠端之間路徑也不同，必須把 VPN、閘道、遠端那一側的上傳以及途中的壅塞都納入考量。參見：RTT 的概念、網路與主機的效能。

產生並傳送畫面的處理

這裡所說的操作回應延遲，是指從在本機操作到看見結果之間的等待。與它有關的不只是 RTT，還有應用程式的處理，以及產生並傳送畫面的處理。也要和只限於畫面傳輸區間的延遲區分開來。參見：從擷取畫面到顯示的測量區間。

輸入從本機送達遠端後，遠端的應用程式會處理輸入並更新畫面，經過編碼的畫面資訊透過網路傳送，再在本機解碼並顯示。在通訊的前後，也有分別由不同 PC 負責的工作。參見：從擷取畫面到顯示的處理。

flowchart TB
    accTitle: 網路的前後也有畫面的處理
    accDescr: 本機的輸入送達遠端，遠端的應用程式處理後產生並壓縮畫面，透過網路傳送的畫面資訊在本機還原成可顯示的形式再顯示出來的流程。
    I["本機：輸入操作"] --> J["網路：傳送輸入"]
    J --> K["遠端：應用程式處理"]
    K --> A["遠端：產生並壓縮畫面"]
    A --> B["網路：傳送畫面資訊"]
    B --> C["本機：還原成可顯示的形式"]
    C --> D["顯示在本機畫面上"]

圖4：在遠端處理與壓縮，透過網路傳送，再在本機還原成可顯示的形式。這些是在不同地方各自進行的工作。

本文所說的編碼，是指在遠端把畫面轉換、壓縮成便於傳送之形式的處理。它和透過網路的傳輸是兩回事，會在遠端花費處理時間。參見：遠端的編碼時間。

本文所說的解碼，是指在本機把收到的畫面資訊還原成可顯示之形式的處理。它和意指解除加密的「解密」是不同的概念。參見：本機的解碼與顯示時間。

如果遠端的壓縮很花時間，即使網路有空檔，也要等待傳送準備完成。即使資訊已經送達，只要本機的解碼或顯示跟不上，更新就會延遲。「公司的 PC 效能很高，所以本機用什麼都可以」並不一定成立。網路的餘裕和兩端處理的餘裕是兩回事。參見：畫面處理的效能計數器。

flowchart TB
    accTitle: 兩端的處理跟不上時的延遲
    accDescr: 遠端的壓縮很花時間時，即使網路有空檔也要等待傳送準備；本機的解碼或顯示跟不上時，即使資訊已送達，更新也會延遲。
    A["遠端的壓縮很花時間"] --> B["網路有空檔也要等傳送"]
    B ~~~ C["本機的解碼跟不上"]
    C --> D["已送達但更新延遲"]

圖5：即使網路還有餘裕，只要兩端的處理跟不上，畫面的更新就會延遲。

文字輸入與捲動的差異

在記事本裡加一個字時，改變的只是畫面的一小部分。捲動圖片很多的網頁時，大範圍的顯示內容會接連改變。RDP 會透過只傳輸變更的部分，以及採用適合內容的壓縮與快取來壓低傳輸量，並不是每次都把整個畫面不經壓縮地送出。工作量會隨著畫面的內容與更新頻率而改變。參見：畫面內容與頻寬的關係。

flowchart TB
    accTitle: 文字輸入與捲動造成的畫面工作量差異
    accDescr: 小範圍的文字變化和大範圍的連續更新，產生並傳送畫面的工作性質不同。
    A{"畫面的變化"} -->|"加一個字"| B["小範圍"]
    A -->|"捲動"| D["大範圍連續變化"]
    B --> E["依變化壓縮並傳輸"]
    D --> E

圖6：即使是同一個連線，加一個字的情境和大範圍持續變動的情境，工作量也不一樣。

即使顯示靜止的文件時負擔很輕，捲動時畫面傳輸也可能失去餘裕。增加遠端的解析度或監視器數量，要處理的畫面也會跟著變大。降低解析度的比較，是觀察減少產生並傳送畫面的工作後動作是否恢復順暢的實驗，並不是只靠像素數決定傳輸量的計算。參見：解析度、畫面更新與壓縮的影響。

應用程式的等待

如果只有業務應用程式的搜尋會停住好幾秒，而同一個工作階段的記事本可以正常輸入，就要確認這個應用程式在等待什麼。遠端的應用程式有時會再向另一台資料庫要求搜尋，或從共用資料夾讀取檔案，並等待對方的回應。這和連接本機與遠端的 RDP 通訊是不同的路徑。參見：從遠端到後端的通訊。

flowchart TB
    accTitle: RDP 的另一端還有通訊對象
    accDescr: 除了連接本機裝置與遠端的通訊之外，遠端的應用程式也可能在等待業務伺服器的回應。
    A["本機裝置"] -->|"RDP"| B["遠端的業務應用程式"]
    B -->|"搜尋與檔案要求"| C["資料庫、共用資料夾"]
    C -->|"正在等待的回應"| B

圖7：RDP 另一端的業務應用程式，有時還在等待另一台伺服器的回應。

負責畫面或輸入的處理一旦卡著耗時的工作，下一次輸入與畫面更新就會延遲。例如在 WPF 中，UI 執行緒長時間被占用時，回應性就會變差。光憑 CPU 整體使用率很低，無法排除特定 UI 執行緒的等待。參見：Dispatcher 與 UI 執行緒。

flowchart TB
    accTitle: 負責畫面與輸入的處理被卡住
    accDescr: 負責畫面與輸入的處理卡著耗時的工作時，下一次輸入與畫面更新會延遲；光憑 CPU 整體使用率很低，無法排除這種等待。
    A["負責畫面與輸入的處理"] --> B["卡著耗時的工作"]
    B --> C["下一次輸入與畫面更新延遲"]
    C -.- D["CPU 整體偏低也無法排除"]

圖8：光憑 CPU 整體使用率，無法排除 UI 執行緒的等待。

依症狀選擇最初的比較

可搬運的量、等待回應的時間，以及產生並顯示畫面的時間，是三件不同的事。只要保持這個區分，就不會把「RDP 很卡」歸結為單一原因，而能從眼前變慢的操作開始調查。

flowchart TB
    accTitle: 先分成三項再調查
    accDescr: 不把「RDP 很卡」歸結為單一原因，而是把可搬運的量、等待回應的時間、產生並顯示畫面的時間分開，從眼前變慢的操作開始調查。
    A["「RDP 很卡」"] --> S
    subgraph S["分開來看"]
    direction TB
    B["可搬運的量"] ~~~ C["等待回應的時間"]
    C ~~~ D["產生並顯示畫面的時間"]
    end
    S --> E["從眼前變慢的操作開始調查"]

圖9：把可搬運的量、等待回應的時間、產生並顯示畫面的時間分開，就能從眼前變慢的操作開始調查。

釐清的目標，是限定要調查變慢的位置，而不是一口氣改動設定、碰巧讓它變快。利用「記事本可以動，只有搜尋會卡住」「打字正常，只有捲動很卡」這類差異，即使在變更通訊設定之前，也能選定調查的切入點。

下表是調查的起點，並不是判定原因的表。請先在同一個工作階段中比較操作，再改變所需的裝置、路徑與顯示條件。

看到的症狀	最先比較的項目	接著要看的地方
多個應用程式的文字都一個一個延遲出現	從另一台裝置、另一條許可的路徑連到同一個遠端	往返時間、輸入等待、遠端整體的負載
輸入正常，但捲動會卡頓	遠端的解析度或監視器數量	遠端的壓縮、畫面傳輸、本機的解碼
只有一個應用程式卡住	同一個工作階段的記事本等是否有回應	該應用程式的處理、磁碟、從遠端往外的通訊
只在使用者變多的時段大家都慢	同一時段的其他工作階段是否也一樣	共用主機的 CPU、記憶體、儲存體，共用線路
開始複製或列印後變慢	暫停自己的傳輸後是否恢復	傳輸或裝置重新導向與畫面通訊的競爭

多個應用程式的文字都延遲出現

如果同一個工作階段的多個應用程式中，文字都一個一個延遲出現，就用另一台裝置或另一條許可的路徑比較同一個操作。對照往返時間、遠端的輸入等待與遠端整體的負載，不要只憑一個數值就決定原因。

只有捲動時卡頓

即使文字輸入正常，捲動圖片很多的網頁時，大範圍的畫面更新也會持續發生。一次改變一項遠端的解析度或監視器數量，在同一個網頁上比較。如果有所改善，遠端的壓縮、畫面傳輸與本機的解碼就是下一步的調查對象。光憑解析度，還無法判斷這三者中是哪一個造成的。參見：畫面內容與解析度造成的負載。

只有一個應用程式卡住

如果只有按下搜尋的業務應用程式停住，就比較同一個工作階段的記事本等是否有回應。其他應用程式能正常運作時，請先調查目標應用程式的處理、磁碟，以及對資料庫或共用資料夾的要求。透過 RDP 操作，和 RDP 通訊是等待的原因，是兩回事。參見：應用程式與後端的效能因素。

只在使用者變多的時段大家都慢

如果同一時段多位使用者都變慢，就向管理員確認其他工作階段的狀況。把共用主機的 CPU、記憶體、儲存體以及共用線路的負載，和出現症狀的時間對照。不要擅自存取其他使用者的記錄或處理，也不要停止他們的工作。參見：共用主機的資源與使用者人數。

複製或列印時變慢

如果自己開始複製或列印的時間和異常重疊，就只暫停獲准停止的傳輸來比較。記錄停止後是否恢復、重新開始後是否又變慢，並調查與畫面以外的傳輸或裝置重新導向之間的競爭。不要用一次停用業務所需裝置的方式來比較。參見：裝置重新導向的影響。

逐一比較條件

不需要依序變更所有設定。先建立比較的基準，只選擇符合症狀的確認項目。變更設定或重新連線之前，請先儲存工作，並記錄原本的值與改回的方法。如果沒有所需的權限或功能，不要勉強啟用，而是交接給管理員。

本機操作和 RDP 操作的條件不一定相同。直接在遠端的實體螢幕上操作很快，可以作為參考，但工作階段與繪製的條件有時會不同。請統一使用者、資料與應用程式的狀態，不要只憑「在實體螢幕上很快」就把原因限定在網路。

比較同一個操作

準備相同的使用者、資料與操作。在共用主機上要確認自己的工作階段，不要停止其他使用者的應用程式或處理。使用另一台裝置或另一條路徑，也僅限於管理員許可的範圍。

在原本的設定下重現變慢的操作，記錄時間與症狀。

在與有問題的應用程式相同的遠端工作階段中，用記事本輸入差不多數量的文字。區分是只有一個應用程式，還是整個工作階段都慢。
在同一個時段確認遠端與本機的負載。

在工作管理員中，遠端要看目標應用程式的 CPU、記憶體與磁碟，本機要看 RDP 用戶端的負載。不只看 CPU 的整體數值，也要確認目標處理程序。參見：負載的調查對象。
在另一台裝置、另一條許可的路徑、顯示條件之中只改變一個條件，重複同一個操作。

如果比較時遠端或應用程式的狀態也同時改變了，也要把這些差異記錄下來。不要把多個條件改變後的結果，當成只改變一個條件的效果。
改回原本的條件，再次確認同一個操作。

如果改回原狀後仍然很快，也可能是暫時的負載變化等因素。不要斷定是變更發揮了作用，而要記錄症狀會重現的條件。

這樣就能湊齊原本狀態、變更後與改回原狀後的結果，比較哪個條件與症狀相對應。有改善的條件是調查的線索，單憑它並不能證明根本原因。

flowchart TB
    accTitle: 限定一次改變的條件
    accDescr: 決定在原本狀態下會重現的操作，只改變一個條件來比較，也確認改回原狀後的結果的流程。
    A["在原本的設定下做同一操作"] --> B["只改變一個條件"]
    B --> C["重複同一個操作"]
    C --> D["改回原狀再確認"]
    D --> E["記錄有改善的條件"]

圖10：在原本狀態、變更後、改回原狀的狀態下重複同一個操作，記錄有變化的條件。

比較遠端的解析度

在捲動等畫面更新很卡的時候進行比較。記錄變更前的解析度與監視器數量，儲存工作後再重新連線。不要把會損害業務所需畫面或文字易讀性的設定，就這樣當成平常的設定使用。

在監視器數量與解析度之中，只改變其中一項。

在 mstsc 中，可以用連線前「顯示」索引標籤中的設定，或指定寬度與高度來比較。參見：mstsc 的顯示指定。
確認遠端桌面的實際大小已經改變，再捲動同一個網頁。

只是把本機的視窗縮小，有時只是把大的桌面縮小顯示而已。請區分動態解析度與 smart sizing，並確認所用用戶端的支援條件。參見：桌面解析度與顯示縮放。
改回原本的設定並重複同一個操作，比較兩端的負載與畫面的動作。

如果同時改成低解析度並合併成一台監視器，就只能算是粗略的比較。如果有所改善，請一項一項改回，把各自的影響區分開來。

如果有所改善，線索就在畫面處理與畫面傳輸的範圍內。3840×2160 的像素數是 1920×1080 的 4 倍，但傳輸量並不一定總是 4 倍。它會隨變更的部分與壓縮而改變，而且解析度的變更也會影響兩端的處理。參見：像素數與傳輸量的關係、畫面處理的確認。

flowchart TB
    accTitle: 降低解析度的比較能看出的範圍
    accDescr: 降低遠端的解析度後，畫面處理與傳輸雙方的負擔都可能改變，因此光憑改善無法把原因限定在網路。
    A["降低遠端的解析度"] --> S
    subgraph S["會改變的處理"]
    direction TB
    B["遠端的畫面處理"] ~~~ C["傳送的資訊量"]
    C ~~~ D["本機的顯示處理"]
    end

圖11：變更解析度這種比較，影響的不只是網路，也包括遠端與本機的畫面處理。

對照複製、列印與症狀

只暫停自己啟動的傳輸等獲准停止的處理。不要停止公司的備份或安全性處理，也不要停止其他使用者的工作。不要一次停用業務所需的音訊與輸入裝置的重新導向。

在開始複製、雲端同步或列印之前與執行期間，記錄同一個操作與負載。

RDP 中除了畫面之外，也會傳送磁碟機、印表機等的資訊。在遠端使用本機裝置的重新導向，在使用期間有時會增加通訊與處理的負擔。參見：裝置重新導向的影響。
在許可的範圍內暫停目標傳輸，再次確認同一個操作。

如果可以重新開始並比較，也要記錄重新開始後的症狀。嘗試停用不需要的裝置重新導向時，也要一次只改一項，並確保能改回原本的設定。

這樣就能判斷傳輸開始與異常、暫停與恢復是否相對應。看出對應關係後，再把畫面以外的傳輸以及共用資源的負載，和管理員的記錄對照。

flowchart TB
    accTitle: 在同一條時間軸上看異常的前後
    accDescr: 在傳輸前、傳輸中、停止後記錄同一個操作與負載，比較異常與作業之間的關係。
    A["傳輸前的操作與負載"] --> B["傳輸中的操作與負載"]
    B --> C["停止後的操作與負載"]
    C --> D["異常與恢復是否對應"]

圖12：觀察同一個操作的慢的程度與負載，在傳輸前、傳輸中、停止後如何變化。

測量等待發生的位置

在本機調查通訊往返與 TCP 連線，在遠端調查輸入佇列的等待與畫面更新。每個數值所測量的區間都有限，因此請對照「測量結果的適用範圍」中的表來解讀結果。

確認 ICMP 與 TCP 連線

執行位置是本機的 Windows 裝置。對象僅限於在公司內部 LAN 或許可的 VPN 中，直接連線到使用標準 TCP 3389 的 RDP 主機的組態。經由 RD Gateway、Azure Virtual Desktop 或使用自訂連接埠的組態，請與管理員決定確認對象。不要開放連接埠或變更防火牆。

輸入許可的連線目標，記錄 ICMP 回應與 TCP 連線的結果。

$target = Read-Host '已獲准調查的 RDP 主機名稱或 IP 位址'
if ([string]::IsNullOrWhiteSpace($target)) {
    throw '請指定連線目標。'
}
    
# 多次查看 ICMP 的回應時間。不能只憑失敗就判斷 RDP 無法連線。
ping.exe -n 20 $target
    
# 僅限於直接連線到標準 TCP 3389 的組態所做的確認。
Test-NetConnection -ComputerName $target -Port 3389 -InformationLevel Detailed
    

把變慢時段與平常的結果，和症狀出現的時間以及實際的連線路徑對照。

20 次 ping 只是短暫的觀察。要記錄數值的起伏與沒有回應的情形，但 ICMP 有時會遭到封鎖。不要只憑平均值就排除斷斷續續的停頓，而要使用連線資訊與管理員的通訊記錄。參見：ping 的測量對象。

TcpTestSucceeded: True 的意思是，成功建立了到指定連接埠的 TCP 連線。它沒有測量頻寬、UDP、驗證後的操作以及畫面的流暢度。Test-NetConnection 沒有用來調查 UDP 的 -UDP 參數。參見：Test-NetConnection 的語法與結果。

判斷時要把路徑與服務的差異考慮進去。在 RD Gateway 等環境中，到主機的 ICMP 或直接 TCP 連線的路徑，有時和實際的 RDP 路徑並不一致。Azure Virtual Desktop 可以使用每個連線的 RTT 與頻寬估計值，但這項診斷功能是針對該服務的。不要只憑平均值就排除短暫的停頓。參見：Azure Virtual Desktop 的連線品質記錄。

flowchart TB
    accTitle: 確認過的路徑與實際的 RDP 路徑
    accDescr: 在使用 RD Gateway 等的組態中，從本機到主機的 ICMP 或直接 TCP 連線的路徑，有時和實際的 RDP 路徑並不一致。
    A["本機裝置"] -->|"ICMP、直接 TCP"| C["RDP 主機"]
    A -->|"實際的 RDP"| B["RD Gateway 等"]
    B --> C

圖13：到主機的 ICMP 或直接 TCP 連線，和實際的 RDP 之間，路徑有時並不一致。

測量輸入佇列的等待

User Input Delay 測量的是在遠端輸入進入佇列之後、到處理程序把它取出為止的等待，並不是從按下按鍵到看見文字的總時間。參見：User Input Delay 的定義。

請在遠端的遠端工作階段內調查。Microsoft 列出的支援條件是 Windows 10 版本 1809 以後、Windows Server 2019 以後。這些對象不需要為了啟用而新增登錄。請確認顯示名稱、權限與計數器是否存在；如果無法使用，就記錄這個事實，並與管理員討論。參見：支援條件與設定。

在同一個工作階段的 PowerShell 中，記下時間與工作階段 ID。
```
Get-Date -Format 'yyyy-MM-dd HH:mm:ss.fff zzz'
(Get-Process -Id $PID).SessionId
query.exe session
    
```
查詢其他使用者的工作階段，可能需要額外的權限。目標處理程序的標準執行個體名稱是 SessionID:ProcessID <Process Image>。不要只憑工作階段 ID，就把其他使用者或同名處理程序的值混在一起。參見：query session 的權限、執行個體的識別。
在 perfmon.exe 中，新增可用的 User Input Delay per Process 或 User Input Delay per Session。

選擇目標處理程序或工作階段，一開始先以預設的 1 秒間隔觀察。請把彙總多個工作階段的彙總執行個體，和個別工作階段的值區分開來。
重現輸入變慢的操作，比較佇列的等待與症狀出現的時間。

個別的測量對象看到的，是測量區間內的最大等待時間。即使數值很低，應用程式取出輸入後的處理，以及結果傳回本機之前的延遲依然存在。

這樣就能調查是否在遠端的輸入佇列中等待。它和包含通訊往返與本機顯示在內的體感時間，是不同的指標。參見：最大值與測量區間的意義。

flowchart TB
    accTitle: User Input Delay 測量的區間
    accDescr: 測量區間是從遠端的輸入佇列到應用程式取出輸入為止，不包含前後的通訊與畫面顯示。
    A["輸入從本機送達"] --> B["進入遠端的輸入佇列"]
    B -->|"測量這裡"| C["應用程式取出輸入"]
    C --> D["應用程式處理與畫面傳輸"]
    D --> E["顯示在本機"]

圖14：測量的是遠端輸入佇列中的等待，和到本機看見結果為止的總時間不同。

調查畫面更新與略過畫格的原因

請準備捲動等畫面會持續更新的操作。RemoteFX Graphics 計數器是否可用以及測量位置，需要依 OS、主機組態與權限來確認。這裡只是讀取可用的計數器，並不是安裝或啟用舊版 RemoteFX 功能的步驟。參見：Graphics 計數器的適用條件。

用 query session 或 qwinsta 確認目標工作階段名稱，選擇對應的計數器執行個體。
在有畫面更新的操作期間，比較 Input Frames/Second 與 Output Frames/Second。

如果輸出比輸入少，表示畫面在中途被略過了部分畫格。請確認 Frames Skipped/Second 中，依遠端、網路、用戶端資源不足分別列出的值。
把略過畫格的原因和兩端與通訊的負載對照，也確認 Average Encoding Time。

如果編碼時間很長，就調查遠端的壓縮處理。如果從輸入端開始畫格數就很少，也可能是應用程式並沒有頻繁更新畫面。靜止畫面下畫格數偏低，本身並不是異常。

從畫面更新期間的輸入輸出、略過畫格的原因與編碼時間，可以縮小調查範圍。計數器的分類只是線索，要搭配實際的負載與連線組態來判斷。參見：畫格數與編碼時間的解讀方式。

flowchart TB
    accTitle: 從畫面的略過畫格縮小調查範圍
    accDescr: 在有畫面更新的操作期間比較輸入輸出畫格數，以略過畫格原因的計數器為線索，和處理、通訊與顯示的負載對照。
    A["比較捲動時的輸入輸出"] --> B["輸出較少就確認略過畫格"]
    B --> C["查看依原因分類的計數器"]
    C --> D["與遠端、通訊、本機負載對照"]

圖15：比較捲動時的輸入輸出，把略過畫格的原因和遠端、網路、本機的負載對照。

不要把畫面傳輸的概念圖或舊資料推廣到所有組態。也有用其他機制傳輸影片與音訊的組態。Graphics 計數器的資料中也有關於舊組態的說明，因此不要把裡面記載的數值，解讀成「所有 RDP 最高都是 30fps」這種共通規格。請先確認功能與數值的適用對象再使用。參見：畫面傳輸與工作負載、Graphics 計數器資料。

測量結果的適用範圍

不要把數值低和操作順暢畫上等號。各項指標的範圍，可以在步驟中列出的 Microsoft 資料中確認。

觀測到的結果	可以知道的事	仍然不知道的事
ping 的回應很小	到該對象的 ICMP 回應時間	實際的整條 RDP 路徑、應用程式處理、畫面顯示是否正常
TcpTestSucceeded 為 True	成功建立到指定目標、指定連接埠的 TCP 連線	UDP、頻寬、驗證後的回應
User Input Delay 很大	目標遠端輸入佇列中的等待	取出輸入後的處理，以及到本機為止的總延遲
更新時輸出畫格很少	調查略過畫格及其原因的線索	單一的根本原因。需要和兩端與通訊的記錄對照
降低解析度後有改善	顯示條件與症狀可能相對應	原因是網路、編碼還是解碼

通訊與 GPU 設定

UDP 與 GPU 的設定，要依照比較與測量所查明的情況來選擇。懷疑是通訊時，先確認連線方式與路徑；懷疑是畫面處理時，先確認 GPU 在哪個階段被使用。

確認 TCP、UDP 與連線路徑

比較與測量顯示通訊可疑時，請和管理員一起確認使用中的用戶端、路徑與套用的原則。即使需要變更設定，也僅限於核准的範圍，並記錄變更前的值與復原方法。不要停用防火牆或驗證，也不要把 RDP 連接埠直接公開到網際網路。

透過連線資訊、產品的診斷記錄與管理員的通訊記錄，確認實際使用的 TCP、UDP 與路徑。

RDP 會依組態與通訊條件使用 TCP 或 UDP。在「Select RDP transport protocols」中，可以在使用 UDP 或 TCP 的設定，與只使用 TCP 的設定之間選擇。由於也有 UDP 連線無法建立時改用 TCP 的行為，光憑連線成功無法得知使用的方式。參見：RDP transport 的選擇與退回。
把症狀出現的時間和路徑、方式對照，只逐一比較必要的設定。

不要一律以為「關掉 UDP 就會變快」而進行變更。請統一 VPN 或閘道的條件、操作與顯示條件後再比較，並把不必要的變更改回來。

掌握方式與路徑之後，就能記錄變更與症狀之間的關係。改成只用 TCP，並不一定每次都能變快。

flowchart TB
    accTitle: 先確認連線方式再比較通訊設定
    accDescr: 區分一般的直接連線與經由閘道或服務的連線，確認實際的路徑與方式後，再進行許可範圍內的比較。
    A["使用的用戶端與連線組態"] --> B["確認實際路徑與 TCP、UDP"]
    B --> C["和症狀出現的時間對照"]
    C --> D["只逐一比較必要的設定"]

圖16：先確認使用中的連線方式與路徑，和症狀對照後，再只比較必要的設定。

RDP Shortpath 是 Azure Virtual Desktop 的機制。它會為該服務建立 UDP 路徑，並依組態使用直接路徑或中繼。如果無法建立，就會退回以 TCP 為基礎的連線。它和用 mstsc 直接連線到公司內部 PC 的情況，不能放在同一張設定表裡。參見：RDP Shortpath 的路徑與退回。

flowchart TB
    accTitle: RDP Shortpath 的路徑與退回
    accDescr: Azure Virtual Desktop 的 RDP Shortpath 會嘗試建立 UDP 路徑，成功時依組態使用直接路徑或中繼，無法建立時退回以 TCP 為基礎的連線。
    A["RDP Shortpath"] --> B{"UDP 路徑"}
    B -->|"建立"| C["直接或中繼"]
    B -->|"未建立"| D["退回以 TCP 為基礎"]

圖17：RDP Shortpath 無法建立 UDP 路徑時，會退回以 TCP 為基礎的連線。

確認畫面處理是否使用 GPU

比較與測量顯示畫面處理可疑時進行確認。請確認畫面處理的測量結果，以及支援的 OS、驅動程式、原則與用戶端。不要只因為裝有 GPU 就變更設定。請先取得管理員的核准，並做好改回原狀的準備。

把遠端應用程式的繪製、RDP 的編碼與本機的解碼分開，選出可疑的階段。

即使有 GPU，也不一定所有階段都會使用 GPU。在 Microsoft 針對 Azure Virtual Desktop 的組態資料中，遠端工作階段的繪製與畫格的硬體編碼，也是分別設定與確認的。參見：繪製與編碼的 GPU 組態與驗證。
依照目標產品的步驟確認實際的使用狀況，在必要的變更前後測量同一個操作。

如果壓縮時間很長，就調查編碼是否使用 GPU。對於在輸入佇列中等待的應用程式，即使變更編碼設定，瞄準的位置也不對。文字的易讀性和影片的流暢度，在畫質、傳輸量與處理負載上的取捨方式也不同。參見：工作負載造成的差異。

這樣就不只停留在有沒有 GPU，而能記錄出問題的階段是否使用了 GPU，以及同一個操作的負載與回應如何改變。沒有帶來改善的變更，要和管理員確認後改回原狀。

flowchart TB
    accTitle: 依階段確認 GPU 的使用
    accDescr: 把遠端應用程式的繪製、RDP 的編碼與本機的解碼分開；即使有 GPU，也不一定所有階段都會使用 GPU，因此要確認可疑階段的使用情形。
    A["遠端應用程式的繪製"] --> B["RDP 的編碼"]
    B --> C["本機的解碼"]
    C -.- D["依階段確認 GPU 使用"]

圖18：即使有 GPU，繪製、編碼與解碼也不一定都會使用 GPU。

重新驗證與交接

要確認改善，除了變更後同一個操作能順利完成之外，還要確認所需的畫質、裝置與業務功能都有維持。也請對照改回原本條件後的結果。如果只是一時恢復，就不要確定原因，而要連同尖峰時段與同時進行的處理一起記錄。

flowchart TB
    accTitle: 確認改善的順序
    accDescr: 確認變更後同一個操作能否順利完成，以及所需的畫質、裝置與業務功能是否維持，並和改回原本條件後的結果對照；光憑一時的恢復無法確定原因。
    A["變更後試做同一個操作"] --> B["確認畫質、裝置、業務功能"]
    B --> C["和改回原條件的結果對照"]
    C -.- D["一時恢復無法確定原因"]

圖19：除了同一個操作的結果，也要對照所需的功能與改回原狀後的結果。

未解決時的交接

沒有改善、無法重現、計數器無法使用，這些也都是有用的結果。請把已經完成的比較和沒能進行的確認分開，用下面的備忘交接給管理員與開發人員。請從共用的記錄中刪除調查用不到的使用者名稱、連線目標等業務資訊。

出現症狀的時間與時區：
遠端 OS、使用的用戶端與版本：
直接連線／VPN／RD Gateway／Azure Virtual Desktop 等：
變慢的操作與應用程式，同一工作階段中其他應用程式的反應：
遠端的解析度、監視器數量：
同時在執行的複製、列印等：
只改變的一個條件，以及改回原狀後的結果：
在遠端、本機觀測到的負載或計數器：

也請補充是否確認了實際使用的 TCP、UDP，因權限不足等原因沒能確認的項目，以及業務上可接受的設定。與其說「網路很慢」，不如說「記事本可以正常打字，但捲動照片時會卡住」，這樣下一位負責人才能在相同條件下調查。

使用者留下會重現的操作與比較結果，管理員則對照連線路徑、共用主機與工作階段的記錄。光憑在 RDP 上等待這個事實，並不能說明造成等待的處理也一定是 RDP。參見：主機與後端的分工。

應用程式的開發人員，要把輸入事件的接收、資料庫與檔案處理的開始與結束，以及反映到 UI 的時間點分開記錄，也要考慮不讓耗時的工作一直占住 UI 執行緒的設計。不過，遠端的處理完成記錄，並不是本機顯示完成的記錄。參見：維持 UI 回應性的處理分離。

參考資料

以下是 Microsoft Learn 的第一手資料，已於 2026年9月17日確認引用的內容。閱讀時請區分各產品的適用條件，並留意這些內容並不是本文已實施的實測。

Microsoft Learn, Analyze connection quality in Azure Virtual Desktop。RTT，以及從遠端擷取畫面到本機顯示為止的延遲之間的區別。診斷功能本身是針對 Azure Virtual Desktop。
Microsoft Learn, Remote Desktop Protocol bandwidth requirements。畫面內容、解析度、畫格更新、壓縮、快取與傳輸量之間的關係。
Microsoft Learn, Diagnose graphics performance issues in Remote Desktop。畫面輸入輸出、略過畫格的原因、編碼時間的確認方法。其中包含舊組態的說明，因此不把數值上限推廣到所有 RDP。
Microsoft Learn, Performance Tuning Remote Desktop Session Hosts。共用主機的負載、從遠端到後端的通訊，以及裝置重新導向的影響。
Microsoft Learn, Threading model。WPF 的 UI 執行緒與 Dispatcher，以及為了維持回應性而進行的處理分離。
Microsoft Learn, mstsc。遠端桌面的寬度、高度與多部監視器的指定。
Microsoft Learn, Supported RDP properties。桌面解析度、動態解析度與 smart sizing 的區別。需要確認支援的用戶端與各產品的適用條件。
Microsoft Learn, ping。以 ICMP Echo 確認回應，以及各個選項。
Microsoft Learn, Test-NetConnection。TCP 連線確認與輸出的意義。
Microsoft Learn, Use performance counters to diagnose app performance problems on Remote Desktop Session Hosts。User Input Delay 的測量區間、對象 OS、執行個體與最大值的意義。
Microsoft Learn, query session。工作階段資訊，以及查詢其他工作階段所需的權限。
Microsoft Learn, ADMX_TerminalServer Policy CSP。RDP 所使用之 TCP、UDP 的選擇與退回。
Microsoft Learn, RDP Shortpath。針對 Azure Virtual Desktop 的 UDP 路徑，以及無法建立時的行為。
Microsoft Learn, Enable GPU acceleration for Azure Virtual Desktop。把繪製與畫格編碼分開的 GPU 組態與驗證。

共用相同標籤的最新文章。能以相近的主題延伸理解。

與本主題相關的服務

本文連結到以下服務頁面，歡迎從最接近的入口查看。

Windows 應用程式開發

支援業務應用程式、設備連動、通訊工具等 Windows 軟體開發。

查看服務聯絡我們

常見問題

整理諮詢這個主題時常見的問題。

測速可以跑到好幾百 Mbps，為什麼 RDP 的輸入還是很慢？: 搬運大量資料的速度，和操作後得到回應所需的時間，是兩回事。輸入的傳送、遠端應用程式的處理、畫面的壓縮、傳輸，以及本機的顯示都與此有關。此外，測速的對象和 RDP 的遠端之間，通訊路徑也不相同。
打字很正常，只有捲動時會卡頓，這是網路的問題嗎？: 不能只歸咎於網路。畫面更新變多時，遠端的繪製與壓縮、通訊、本機的解碼與顯示，任何一個環節都可能跟不上。一次改變一項遠端的解析度或監視器數量來比較，必要時再調查與繪製相關的計數器。
ping 很快，就代表 RDP 的通訊正常嗎？: 光憑這一點無法判斷。ping 測量的是對 ICMP 的回應，不會測量 RDP 的畫面傳輸或應用程式的處理。在使用 RD Gateway 等的組態中，路徑也可能不一致。沒有回應時，也請區分是 ICMP 遭到封鎖，還是 RDP 本身無法連線。
User Input Delay 是從按下按鍵到出現文字的時間嗎？: 不是。它是一個計數器，測量的是在遠端輸入進入佇列之後、到處理程序把它取出為止的等待時間。它並不是涵蓋通訊往返、取出後的應用程式處理，以及畫面壓縮、解碼與顯示在內的體感延遲。
RDP 很卡時，應該停用 UDP 嗎？: 不建議一律這麼做。先確認實際的連線方式、路徑與套用的原則。有時是因為無法使用 UDP 而退回 TCP，改成只用 TCP 也不一定每次都會變快。在管理員的許可下把條件統一後再比較，並把不必要的變更改回來。

作者檔案

本文作者的個人檔案頁面。

Go Komura

小村軟體有限公司代表

以 Windows 軟體開發、技術諮詢與故障調查為中心，擅長處理仍留有既有資產的專案，以及原因難以看清的故障調查。

查看檔案聯絡我們

公開連結

ORCID GitHub LinkedIn X COM_BLAS COM_BigDecimal

回到部落格一覽