最近看到 NVIDIA 已經把 Smooth Motion 正式放進 NVIDIA APP，剛好這功能可以拿來補影片播放時的幀數，所以順手整理一下在 mpv 上的設定方式。這篇主要偏筆記性質，方便之後自己重配環境時不用再重新找一次資料。

功能簡介

• NVIDIA 新增的 Smooth Motion（平滑運動）功能，主要用途就是在影片播放時做補幀。
• 目前正式版已經可以直接使用，在台灣版 NVIDIA APP 裡面顯示名稱就是「平滑運動」。
• 如果你本來就有在用 mpv 看影片，這功能算是相對省事的補幀方案，不用再另外多裝一整套補幀軟體。

最近幫朋友測了一輪 mpv 的 AFMF 補幀設定，確認在條件符合的情況下，的確可以正常啟用，而且搭配 AI 畫質拉升一起使用時，整體觀看體驗也不錯。雖然我自己手上沒有 AMD 內顯或外顯，沒辦法在自己的機器長時間交叉驗證，但至少這次實測結果是可行的，所以先把步驟整理成筆記，之後要重配環境比較不會再重踩一次。

這篇主要會整理幾個重點：mpv 啟用 AFMF 需要什麼條件、mpv.conf 應該怎麼寫、濾鏡怎麼確認有沒有真的生效，以及和 VapourSynth 串接時要注意哪些細節。

最近原本想測試看看，改用 MPC 搭配 mpv-lazy 腳本後，SVP Pro 4 的 RIFE 補幀和影片超分會不會比直接用 MPV-Lazy 更順。結果先講結論：效能差異沒有我預期的大，整體表現差不多，而且 DRBA 補真在這一套流程下甚至沒辦法順利跑起來。

如果你只是想找一個比較省事的方法，其實不用特地為了這件事重做整套播放器環境。不過如果你平常主力還是 MPC，想把 mpv-lazy 的 VapourSynth 腳本接進來，這篇還是可以當成一個實作紀錄。

起因

之前用 manga-image-translator 翻譯漫畫時，模型每次回答前都會先「思考」一輪，導致單張圖從模型回應到產圖大約要 20 秒。

剛剛我直接從程式碼把思考模式關掉，模型 1～3 秒就能回傳翻譯，整張圖平均 7 秒（6～9 秒）翻完。

Manga Image Translator 是一套可以自動辨識並翻譯漫畫圖片文字的工具。這篇主要記錄我怎麼透過 Docker，把它的 Web 服務架在有 NVIDIA GPU 的主機上，讓後續翻譯速度更穩定，也比較省手。

撰文時間：2026 年 7 月。
本文使用的映像標籤是浮動版本 :main，如果官方後續調整啟動方式或參數，本文內容可能也要跟著修改。

這篇整理我實際測過的 manga-image-translator 安裝流程，目標是讓你在 Windows + NVIDIA GPU 環境，盡量一次把漫畫翻譯服務跑起來。

官方文件連結：

• manga-image-translator README_CN

最近為了跑 CUDA Docker 服務，把 WSL 更新到新版，結果 Docker Desktop 直接打不開。

其實我平常不太敢亂升級，怕的就是這種「看起來只是更新，實際上整個開發流程卡住」的狀況。這次查了很久，最後找到一個看似不相關、但真的有效的修復方式，順手記錄下來，避免下次再踩一次。

最近公司專案設定 API Gateway 無法順利導向後端 API 位置。檢查 Azure 的配置時發現，Azure 的路由規則是有上下順序的，但 Nginx 並不是這樣運作。經過研究才發現 Nginx 的 location 匹配規則和 Azure API Gateway 的邏輯完全不同，這裡就做個完整整理。 核心匹配順序 (從高到低) Nginx 在處理請求時，會遵循以下邏輯來決定最終使用的 location： 順序 修飾符 匹配類型 匹配規則與行為 1 = 精確匹配 全字串完全符合。一旦命中，立刻停止搜尋，直接採用此設定。 2 ^~ 前綴匹配 (阻斷) 如果該前綴是「最長匹配」，立即停止搜尋，不檢查正規表達式。 3 (無修飾符) 普通前綴匹配 尋找最長符合的前綴並暫存起來，但會繼續往下檢查正規表達式。 4 ~ / ~* 正規表達式 依據在設定檔中出現的先後順序比對。第一個命中的立刻停止搜尋。 一句話秒懂 「精確優先；最長匹配帶 ^~ 直接贏；否則交給正規表達式按順序比對（先到先得），全都沒命中才由最長前綴保底。」 完整的演算法決策流程 如果我們把 Nginx 的「大腦」拆解成三個階段，邏輯會變得非常清晰： 第一階段：前綴字串比對 (Literal/Prefix Strings) 檢查 = 精確匹配：如果有完全一致的 URI（例如 /index.html），直接採用並結束。 尋找最長前綴：找出所有普通字串（包含無修飾與 ^~）中，匹配長度最長的那一個。 判斷是否阻斷： 如果這個「最長匹配」帶有 ^~ 修飾符，Nginx 認為這已經足夠明確，會直接採用此設定並停止搜尋。 如果只是普通字串（無修飾），Nginx 會將此結果暫存起來作為備選方案，然後進入下一階段。 第二階段：正規表達式比對 (Regular Expressions) 按順序掃描 ~ 或 ~*：從設定檔由上往下逐行讀取。 只要有任何一個正規表達式成功匹配，就會立即採用此規則，並丟棄第一階段暫存的備選方案。 第三階段：最終終點 保底機制：如果所有的正規表達式都沒有匹配成功，Nginx 才會最後採用第一階段暫存的最長普通前綴。 實戰範例與差異對比 透過以下配置，你可以清楚看到不同修飾符帶來的行為差異：

在進行 OAuth 串接開發時，常會遇到「只有測試環境機器才能存取後端服務」的問題。這時要如何在本地端（Localhost）進行除錯與整合測試？

本文將分享一個實用的解決方案：透過 mkcert、SSH Tunneling 以及 Reverse Proxy (Caddy) 的組合，在本地建立一個模擬真實環境的網路架構。

核心概念

當我們在本地開發時，往往無法直接連線到遠端的生產或測試環境 API。透過以下流程，我們可以將流量導向正確的地方：
前端 → Redirect 至後端入口 → 後端 → 目標服務

對於許多剛接觸網路架構或自建服務的工程師來說，設定 Port Forwarding (DNAT) 讓外部網路能夠存取內網的 Web 服務是家常便飯。然而，當我們嘗試「在內網環境中，直接透過外部 IP (Public IP) 連線到內網伺服器」時，卻常常會遇到一種詭異的現象：有些環境可以通，有些環境卻完全連不上。

最近這篇文章看到有人說這個問題。這讓我回想起自己的經驗：以前在家裡使用中華電信數據機加上 ASUS Router 時，設定好 DNAT 後，內網直接打 Public IP 就能無縫連上 Web 服務。但同樣的操作，在我朋友家那台企業級的 Fortigate 防火牆上卻行不通。

為什麼會有這樣的差異？答案其實藏在一個名為 NAT Loopback（或稱 Hairpin NAT、NAT Reflection）的路由器功能中。