VPN 協定與線路指南

連線分層：協定、線路與應用程式

先釐清資料實際經過的路徑

瀏覽網頁時，通常會先由應用程式發起網域名稱解析，接著建立與目標的連線，再交換網頁內容。啟用代理用戶端後，應用程式資料可能先進入系統代理或虛擬網路介面，再由用戶端依規則決定直連或交由遠端出口處理。出口接著與目標服務通訊，並沿著連線傳回結果。任何環節有所等待，都可能讓網頁載入變慢，但成因未必相同。將「應用程式到用戶端」、「用戶端到入口」與「出口到目標」分開記錄，比反覆更換協定更容易找出問題。

系統代理與虛擬網路介面的涵蓋範圍也不相同。前者仰賴應用程式遵循系統設定；後者可以接管更廣泛的網路流量，但仍受用戶端規則、系統權限與應用程式行為影響。瀏覽器能連線到目標，不代表編輯器、命令列工具或會議軟體也走相同路徑。應先確認發生問題的應用程式是否經過用戶端，再查看命中了哪條規則。若規則未涵蓋目標，更換遠端節點也不會改變這部分流量的去向。

區分協定功能與服務提供範圍

Shadowsocks、VMess、Trojan、VLESS、Hysteria2 與 TUIC 探討的是代理資料如何組織、驗證與傳輸。TCP、UDP、TLS 與 QUIC 則屬於相關但不同的技術層次：有些負責可靠傳輸，有些負責加密連線，有些則在傳輸中提供獨立資料流。用戶端可能會將這些選項組合顯示，因此介面上相鄰的欄位未必屬於同一類概念。只比較名稱，容易把傳輸方式的差異誤認為代理協定本身的差異。

即使是同一種協定，也可能因傳輸設定、加密方式、核心實作與伺服器調度而有不同表現。本頁不提供脫離實際環境的速度排名，也不會將特定協定視為服務品質保證。VPNJoin 提供 110+ 個國家 / 160+ 條線路；涵蓋範圍代表可選擇的出口規模，不表示每個出口的路徑相同，或都適合所有應用程式。查閱線路清單時，應一併留意地區與線路類型，並以實際訂閱提供的選項為準。

建立可重複的觀察方式

評估使用體驗前，先釐清要解決的是首次載入緩慢、傳輸途中停頓，還是裝置從背景恢復後無法連線。首次載入會受到解析與連線建立影響；持續傳輸更仰賴傳輸量與壅塞控制；連線恢復則可能受系統休眠與網路切換影響。分別描述這些現象，有助於避免用下載速度解釋會議聲音斷續，也能避免以用戶端顯示的連線狀態取代應用程式測試。狀態正常只代表某項檢查通過，不一定涵蓋連線至目標服務的完整過程。

進行對照測試時，保持相同裝置、本地網路與目標任務，只更動要比較的選項。記錄所選地區、協定、使用時段、應用程式的狀況及切換後的恢復情形，不必記錄瀏覽內容或洩露訂閱憑證。若本地網路有所變化，應另建一組觀察紀錄，不要將不同環境的結果混為協定結論。如此取得的是可供決策參考的個人紀錄，而非看似精確卻無從解讀的排行榜。

先確認流量是否進入用戶端，再判斷協定是否適合目前的線路。若尚未釐清路徑，測速結果往往回答的是另一個問題。

Shadowsocks、VMess、Trojan 與 VLESS

Shadowsocks 與 VMess：留意完整組合

Shadowsocks 的代理轉送設計相對簡潔，實際安全性取決於採用的加密方案與實作。它可以承載不同類型的應用程式流量，但仍須分別確認用戶端是否支援相關功能，以及伺服器是否啟用對應轉送。選擇時不應只看名稱是否熟悉，也要確認訂閱能否由目前使用的用戶端正確辨識。若某個欄位不受支援，匯入成功可能只表示文字內容已被讀取，不代表執行時的設定完整有效。

VMess 將身分驗證與代理資料處理納入協定設計，也可搭配不同傳輸方式。實際運作不只由 VMess 這個名稱決定：外層傳輸是否增加連線步驟、是否經過額外轉送，都可能改變連線建立所需時間與資源消耗。某些相容選項也仰賴用戶端與伺服器對時間、驗證方式及設定的共同理解。若特定協定無法單獨連線，應檢查系統時間、用戶端支援狀況與訂閱更新狀態，而不是直接認定整條網路都無法使用。

Trojan 與 VLESS：釐清安全邊界

Trojan 通常透過 TLS 連線承載代理通訊，連線時須考量憑證驗證、伺服器名稱與驗證資訊之間的搭配。憑證檢查不是可以任意關閉的裝飾功能，而是用來確認連線對端是否符合預期。發生憑證錯誤時，應先檢查裝置時間、網路是否需要登入網頁驗證，以及訂閱是否仍有效。為了消除錯誤提示而略過驗證，會改變原有的信任邊界，也可能掩蓋真正的設定問題。

VLESS 的基礎設計著重於輕量驗證與轉送，本身不應等同於完整的加密方案。通訊保護取決於搭配的安全傳輸方式與實際設定，因此僅說「使用 VLESS」，不足以描述連線的安全性或資源成本。閱讀用戶端資訊時，應一併了解傳輸方式、安全層與伺服器名稱。不要將從其他來源取得的欄位拼接到現有訂閱中；看似相同的名稱可能對應不同入口，混用容易導致驗證、路由或憑證比對失敗。

比較時別將實作差異當成協定定律

只要路徑狀況良好，這些協定都可能滿足日常使用需求，但不能只按名稱排列連線成本。連線是否重複使用、目標是否需要獨立連線，以及用戶端是否已有可用連線，都會改變等待時間。對於頻繁發送短請求的網頁與編輯器，減少重複建立連線通常有所幫助；持續傳輸則可能更受路徑容量與壅塞狀況影響。同一協定在不同用戶端上的表現，也會受到快取、調度與背景執行策略影響，不能直接套用他人的結論。

維持相容性時，優先使用面板提供的訂閱匯入方式，並從面板取得適用於目前平台的用戶端下載連結。訂閱更新後若發生問題，可比較更新前後的協定類型與傳輸選項，但不要在公開回報中貼出完整設定。支援某種協定代表具備相關功能，不等於保證特定線路的品質。若必須選擇相容範圍較明確的方案，應以目前裝置能正常運作的組合為起點，再比較目標應用程式的完整使用情況。

Hysteria2 與 TUIC：了解 QUIC 的取捨

獨立資料流能解決與無法解決的問題

Hysteria2 與 TUIC 都運用 QUIC 的相關功能來組織代理通訊。QUIC 建立於 UDP 之上，結合加密連線與傳輸機制，並支援在同一連線中承載多個邏輯資料流。不同資料流不必因其中一條缺少資料，就一律等待同一段有序位元組；這有助於減少特定形式的相互阻塞。不過，應用程式本身的依賴關係依然存在：若頁面必須先取得某項資源才能繼續顯示，傳輸層無法替應用程式消除這段等待。

獨立資料流不代表各資料流擁有互不影響的網路容量。它們通常仍共用底層路徑、傳送額度與壅塞回饋。無線連線不穩或出口壅塞時，所有任務都可能變慢。若將「避免部分隊頭阻塞」理解為「封包遺失時不受影響」，就會高估協定的能力。較精確的預期是：在網路條件合適且支援的情況下，它提供不同於傳統串流承載的調度方式；是否改善體驗，仍須依任務實際驗證。

兩種實作應分開看待

Hysteria2 提供以 QUIC 為基礎的代理傳輸，並具有與頻寬估算及壅塞處理相關的設計選項。某些設定會影響傳送行為，不能把填入較大的頻寬數值當成加速按鈕。若設定值超出本地或遠端路徑的承載能力，可能增加排隊、封包遺失及其他應用程式的等待時間。應優先保留訂閱提供的參數；需要調整時，應先了解欄位代表的意義與單位，並確認用戶端及伺服器皆支援。

TUIC 同樣透過 QUIC 承載代理連線，但其連線組織、轉送細節與用戶端實作並不完全等同於 Hysteria2。兩者共用某些底層特性，不代表驗證資訊、參數或匯入格式可以互換。實際使用時，應確認所選用戶端是否支援訂閱中的特定組合，以及 UDP 轉送是否符合應用程式需求。若只有某個用戶端發生異常，應先區分實作相容性問題與線路問題，不要直接照搬另一種協定的操作說明修改欄位。

UDP 路徑條件決定適用範圍

部分飯店、訪客網路或企業網路環境，對 UDP 採取的策略可能與 TCP 不同。可能出現無法建立連線，或雖然連線成功、持續傳輸卻不穩定的情況。此時改用可運作的 TCP 承載方案是為了確保相容性，不代表 QUIC 技術本身失效。請先完成接入網路要求的網頁登入，再測試代理連線；若本地網路尚未取得正常存取權限，反覆切換遠端出口通常只會增加排查干擾。

行動裝置從 Wi-Fi 切換至行動網路時，QUIC 的連線設計可為連線遷移提供基礎；但能否維持既有代理任務，還取決於用戶端、伺服器、作業系統與實際設定。應用程式本身也可能主動重新建立連線，因此不能將協定功能宣稱為不中斷保證。評估時應觀察切換後的實際任務是否恢復、是否需要手動重新連線，以及系統休眠後是否仍能繼續使用。一次成功的測試不能取代不同使用狀態下的驗證。

UDP 不代表應用程式資料不可靠。QUIC 可在 UDP 之上提供可靠資料流；是否需要重新傳送及如何進行壅塞控制，取決於上層傳輸設計，而非只看底層名稱。

連線建立與資源使用的比較方式

冷連線與既有連線是不同的測試

連線建立所需的等待時間，可能來自網域名稱解析、至入口的傳輸連線、安全交握、代理驗證，以及出口連至目標的連線。有些步驟可以重疊或重複使用，因此不能將各段延遲直接相加。用戶端首次啟動後開啟網頁，與已有連線時再次造訪，測量到的不是相同成本。比較協定前應註明是冷啟動還是熱連線，否則快取與連線重複使用帶來的改善，很容易被誤認為協定優勢。

「頁面開始顯示」與「內容全部傳輸完成」也應分開觀察。前者較容易受到解析、交握與伺服器回應影響；後者還取決於資源大小、並行請求與傳輸容量。編輯器儲存檔案後等待遠端回應，通常更在意短請求的往返時間；下載檔案則更重視穩定的傳輸量。選擇指標時應對應實際任務，不能只因測速圖表較好看，就認定互動回應一定有所改善。目標服務本身的處理時間也可能是主要等待來源。

連線重複使用與加密成本須配合負載評估

重複使用連線可以減少反覆建立連線的次數，但也會讓更多任務共用同一條承載連線。若承載層需要依序交付資料，遺失的資料可能延後其他邏輯任務；即使使用獨立資料流，仍須共用路徑資源。因此，連線重複使用並非越多越好，也不是所有應用程式都應強制合併。用戶端通常會採用預設調度策略，一般使用時建議先維持預設值，再針對可穩定重現的問題逐項調整，避免同時變更連線重用、解析與路由規則。

資源消耗來自加密運算、資料複製、封包處理、連線維護與記錄等環節。裝置是否具備合適的硬體加速，以及用戶端核心如何實作，往往比協定名稱更能影響處理效率。大型檔案傳輸與大量短連線，對處理器及記憶體造成的負擔並不相同；背景應用程式頻繁發送請求，也可能讓原本負載較輕的代理持續運作。若看到處理程序的資源使用量升高，應一併查看目前任務，而不是將所有消耗都歸因於加密。

以可解釋的對照取代綜合評分

在 Windows、macOS 或 Linux 上，可使用系統內建的工作監視工具查看用戶端的處理器、記憶體與網路活動。測試時先關閉無關的大量傳輸任務，固定目標應用程式，分別觀察啟動、持續使用與閒置階段。留意資源使用量是否隨任務合理變化，以及任務結束後能否下降。不同作業系統對程序統計與快取的計算方式不盡相同，因此不宜直接比較跨平台的螢幕截圖，更不要將單次峰值視為長期資源需求。

若用戶端顯示連線錯誤，先查看錯誤類型，再決定下一步。解析失敗應檢查網域與解析路徑；驗證失敗應檢查訂閱狀態與設定；憑證錯誤應檢查時間與名稱；只有連線逾時時，才進一步排查入口是否可連線。錯誤提示只能提供線索，不能只憑某個字眼就下結論。透過其他目標、其他線路與本地直連任務進行對照，逐步縮小範圍，通常比重新安裝所有元件更能保留證據，也更方便在支援工單中說明情況。

行動裝置耗電：無線網路喚醒比協定名稱更重要

無線連線持續活躍會增加耗電

行動裝置耗電不只來自加密運算。無線通訊需要維持收發狀態；連線閒置後何時進入省電狀態，以及何時因新資料而喚醒，都會影響電量。背景應用程式持續發送請求、代理連線保活，以及網路不穩時的重新傳送，都可能讓裝置頻繁恢復活躍。即使傳輸資料量不大，這類活動也未必省電。因此，要判斷某種協定是否省電，還須考量實際流量模式，不能只看用戶端下載了多少資料。

保活機制用於協助維持某些連線或中間設備的對應狀態，但傳送得更頻繁不代表更穩定。過於頻繁的保活可能增加無線活動；間隔過長則可能讓部分網路中的連線更容易閒置失效。合適的設定取決於路徑與實作，沒有適用所有裝置的通用答案。通常保留訂閱的預設設定，比照搬網路上的參數更穩妥，尤其不要在沒有可重現條件時，同時修改保活、重試與背景執行設定。

分別了解 iOS 與 Android 的背景限制

iOS 上的網路延伸功能受系統生命週期與資源管理限制；應用程式前景介面與實際承載流量的延伸功能，也不一定是同一個執行單元。關閉介面、鎖定螢幕或切換網路後的狀態，不能只根據介面動畫推斷。若背景恢復異常，應查看系統連線狀態，並透過實際應用程式驗證。下載用戶端時，請使用使用者面板中的用戶端下載入口，避免將其他來源的匯入說明誤認為目前用戶端的操作規範。

Android 裝置的電池管理可能同時受到系統設定與裝置製造商策略影響。背景程序受到限制後，症狀可能類似線路中斷，但更換節點未必能改善。應觀察問題是否總在鎖定螢幕或長時間閒置後出現，再檢查用戶端所需的背景權限。只調整確有需要的應用程式設定，不必為了排查問題而關閉整個系統的省電機制。系統升級後若出現變化，也應重新確認權限與網路設定是否維持原狀。

比較耗電情況時，務必維持相同使用條件

比較前固定螢幕亮度、前景應用程式、本地網路與任務類型，避免一組測試一邊看影片，另一組卻以閒置待機作比較。行動網路訊號微弱時，裝置本身的無線通訊成本可能增加；切換至 Wi-Fi 後有所改善，也未必是協定變更造成。系統電池用量統計中的百分比不是獨立的絕對耗電量；其他應用程式活動減少時，用戶端的占比可能上升。應綜合電量變化、發熱情形與任務完成狀況來判讀。

實用的選擇方式通常是：在連線正常的前提下，優先採用能控制背景活動、且網路切換後容易恢復的組合。若裝置持續發熱，先檢查是否有上傳、同步、反覆連線或大量錯誤記錄，再進行協定對照。裝置數量不限，不代表所有閒置裝置都需要持續傳輸；依任務需求啟用連線，更容易找出異常活動。若涉及帳戶流量與重置規則，請查閱方案說明，不要以電池統計取代流量紀錄。

排查時可先確認「是否訊號微弱」、「是否在背景重試」與「是否受到休眠限制」，再比較協定。耗電問題往往來自使用狀態，而非某種協定天生耗電。

線路拓撲：直連、中轉與專線

入口、承載與出口各自負責什麼

了解線路時，可以將路徑拆成使用者到入口、入口到出口，以及出口到目標服務。直連通常表示用戶端直接連至目標地區的入口或出口；中轉則會增加轉送節點；專線標籤通常表示某段承載採用特定的專用互連安排。這些名稱描述的是組織方式，並非完整的效能保證；不同服務使用標籤的範圍可能不同，應配合線路說明理解，不能只憑標籤推斷整段路徑是否為專用線路。

地理距離會影響傳播延遲，但網路路徑不一定沿著地圖上的直線前進。電信業者互連、上游路由與目標網路的接入方式，都可能讓看似較近的出口繞道。相反地，中轉雖多經過一個節點，也可能因避開品質較差的互連路段而改善實際體驗。節點數量只是路徑結構資訊，不能單獨決定速度。選擇線路時，應觀察應用程式連至出口、再到目標的整體過程，而不只比較用戶端連至入口的回應時間。

三種組織方式各有適用條件

直連的結構較容易理解，轉送層級較少，也方便找出用戶端與遠端入口之間的問題。不過，它受到本地電信業者連至遠端網路的路徑影響也較直接。中轉可以調整承載路徑，讓用戶端先連至較合適的入口，再由入口轉送至出口；代價是增加了需要共同運作的環節。若中轉入口或後續承載壅塞，也可能造成排隊。因此，「中轉」並非天生較差，也不足以單獨保證穩定性。

IEPL 專線通常用來描述特定承載區段採用的專用互連方式，有助於理解其與一般公共網路轉送的結構差異。不過，使用者的無線網路接入、用戶端處理，以及出口到目標的最後一段，不會因為承載標籤而自動改變。即使中間鏈路狀況良好，目標服務負載或本地無線封包遺失仍會影響使用體驗。閱讀線路清單時，應將專線視為選擇線索，再透過實際任務驗證，而非將其延伸解讀為端對端效能保證。

選擇地區也須考量目標服務的位置與策略

辦公文件、程式碼託管平台與影音平台可能部署於不同網路。適合某個網站的地區，不一定也適合其他服務；即使出口位於同一地區，也可能因上游互連不同而有不同表現。若涉及帳戶地區、內容授權與平台風險控管，線路能夠連線不代表目標平台一定提供相同功能。請遵循平台條款並完成正常登入驗證，不應將更換出口當成解決所有帳戶提示的通用方法。

為長期辦公選擇線路時，可保留適合常用目標的主要路徑，並明確訂出哪些情況才需要切換備用路徑。頻繁自動切換出口可能導致長時間連線重新建立，也會讓排查紀錄失去可比性。查看國家、地區與線路類型後，先固定出口完成實際任務，再觀察不同時段的變化。VPNJoin 涵蓋 110+ 個國家 / 160+ 條線路；服務涵蓋規模提供更多選擇，不代表每個目標在每個地區都有相同體驗。

封包遺失、延遲抖動與尖峰時段壅塞

相似的卡頓可能來自不同原因

封包遺失表示資料未如預期抵達，原因可能是無線干擾、裝置處理能力不足、路徑壅塞或網路策略。延遲抖動描述資料抵達時間的變化；即使平均往返時間看似正常，傳輸時快時慢也會影響語音與即時互動。可靠傳輸可透過重新傳送補足遺失內容，但恢復需要時間；即時服務有時寧可捨棄過時內容，也不願等待補傳。因此，網頁瀏覽、下載與會議對同一網路問題的反應可能大不相同。

當某段路徑的到達流量超出處理能力時，就會發生壅塞。設備可能先將資料排入佇列；佇列累積後，延遲會上升，之後才開始丟棄資料。此時使用者不一定會看到頻寬完全用盡，也可能是檔案仍能下載，但點擊操作與語音明顯變慢。本地接入的上傳量占滿時，也可能拖慢回應資料與其他請求。排查卡頓時應同時檢查上傳與下載，不要因為下載任務不多，就排除本地壅塞的可能性。

依範圍、時段與目標逐步縮小問題

尖峰時段變慢可能來自家中 Wi-Fi、接入網路、跨網互連、線路承載或目標平台。先觀察同一本地網路上的一般連線是否也變慢，再比較同一目標透過不同出口的表現。若只有特定目標異常，優先考慮目標端或出口至目標的路徑；若所有代理目標都異常，但本地連線正常，再繼續檢查入口與承載。這種分層排查比直接認定「尖峰時段伺服器滿載」更嚴謹，也能減少無效切換。

路徑診斷工具可提供輔助線索，但中間設備未回應探測，或對探測請求限速，不代表實際服務流量也在該處遺失。應配合目標的實際使用情況判斷，避免將某一跳顯示異常視為問題所在。用戶端的延遲檢查也可能採用不同於目標應用程式的探測方式，結果只能說明相應檢查條件。需要回報問題時，請保留工具名稱、測試目標類型與應用程式狀況，讓支援人員了解測量內容。

更換協定前，先排除可控制的變因

優先暫停背景同步與大型檔案上傳，靠近無線基地台，或在條件允許時改用有線網路進行對照。若情況明顯改善，代表值得進一步檢查本地網路接入。若只有特定時段出現異常，請記錄時段與所選線路；不要在切換網路、地區與協定後，才將結果混在一起比較。使用 QUIC 類協定時，還須確認目前網路實際支援 UDP；使用串流型承載時，則應留意封包遺失造成的等待是否與任務停頓相符。

適度切換線路有助於避開局部路徑問題，但自動選擇也有其限制：過於頻繁地檢查或切換，可能額外消耗資源並中斷既有連線。直播前應先選好線路；參與會議時，應優先維持可用路徑，而非追求更低的探測數值。可參考體育賽事直播的線路選擇建議，了解即時服務的取捨。若問題一再發生，請透過面板工單描述可重現的條件，而非提交未經驗證的速度結論。

「回應變慢」可能早於「資料遺失」。若下載仍在進行，但互動明顯卡頓，請先檢查排隊與上傳使用量，不要只關注封包遺失提示。

依情境選擇連線方式並保留排查紀錄

辦公、AI 工具與直播關注的環節各不相同

瀏覽網頁與處理辦公文件時，通常需要兼顧短請求的回應速度與長時間連線的穩定性。先選擇目前用戶端相容性良好的協定組合，再固定適合目標服務的出口。編輯器與 AI 工具還須另外確認代理設定：瀏覽器連線成功，不代表編輯器中的請求也走相同路徑；整合式終端機也可能使用不同的環境設定。出現回應停頓時，應分辨請求尚未建立、連線中斷，或目標服務正在處理；不要將所有等待都歸因於線路。

直播與即時會議更重視持續可用性、延遲抖動與恢復狀況。選擇線路時應透過實際播放或通話測試，而非只看探測結果；節目來源、內容傳遞網路與應用程式緩衝也會影響表現。大型檔案傳輸則更容易暴露持續傳輸量與裝置處理能力的限制。若傳輸使其他應用程式明顯變慢，應先控制並行作業與背景任務，再考慮更換協定。協定調校無法取代合理分配本地網路容量，也不會改變目標平台的內容授權。

整理成可還原的選擇步驟

從面板取得用戶端並更新訂閱後，先以預設設定建立可正常運作的基準。確認應用程式規則、系統時間與目標連線正常後，再比較其他可選協定。每次只更動一個因素，記錄變更前後的任務表現，並保留恢復預設設定的方式。若某個選項在目前網路下無法建立連線，使用已驗證可相容的方案繼續工作即可，不必為了追求較新的協定名稱而勉強排錯。穩定完成任務，比保留複雜設定更重要。

驗證連線時，可參考出口 IP 與 DNS 檢查教學，分別檢查網路出口、解析行為與目標應用程式。出口有所變化，只代表受測請求經過相應路徑；DNS 結果也須配合系統、瀏覽器與用戶端的解析設定理解。VPNJoin 不記錄日誌的政策屬於服務隱私承諾，不應延伸解讀為對終端裝置、瀏覽器或目標平台行為的絕對保證。帳戶安全與應用程式權限仍須由使用者妥善管理。

分開考量技術選擇與費用方案

流量需求可依實際任務與面板紀錄評估，不宜透過協定名稱推算。VPNJoin 月訂閱方案為 ¥9.9/月含 60GB、¥18/月含 250GB、¥28/月含 500GB，流量自開通日起每月重置，中途升級時，差額會依剩餘天數折算。流量包為 ¥158/300GB、¥358/1000GB、¥658/3000GB，用完為止，永久有效。詳細選項請參閱訂閱方案與流量包；計費流量不應被誤解為協定速度或線路優先級。

VPNJoin 支援 Windows / macOS / iOS / Android / Linux，裝置數量不限，提供 60 天無理由退款，支援支付寶 / 微信 / USDT。建立帳戶無需電子郵件地址，只要使用者名稱與密碼即可完成。遇到問題時，可前往使用者面板工單，提供平台、協定、線路地區、本地網路類型、錯誤類別與已進行的對照測試。請勿提供密碼、完整訂閱網址或驗證欄位。清楚描述可重現的步驟，比缺少背景資訊的螢幕截圖更有助於找出問題。

最後，將適合日常任務的組合整理成簡短使用紀錄：何時使用主要路徑、哪些狀況需要切換，以及切換後如何確認已恢復。網路條件會改變，紀錄的價值不在於替協定貼上永久標籤，而是保留判斷依據。需要重新匯入或確認操作順序時，請返回快速入門教學；需要查找特定問題的說明時，請參閱常見問題。先釐清問題所在層面，再選擇工具，才能讓每次調整都留下易於理解的結果。