1 為何大螢幕要拆成「本機用戶端」與「旁路閘道」兩條主軸
使用者實際搜尋的問題往往濃縮成一句話：客廳的 Apple TV 要怎麼讓 Netflix 走得到、且盡量不卡。技術上可拆成兩層：第一層是 tvOS 是否願意讓您裝一個能讀 Clash 設定檔的應用程式，並在系統內用 VPN 或類似通道把符合規則的流量交給核心處理；第二層則是「乾脆不要和電視作業系統纏鬥」，改由區網內另一台 旁路由或 NAS／軟路由當 閘道，凡是指向它的裝置都自動經過 Clash 分流。兩者不是互斥：同一個家裡，手機可繼續用熟悉的桌面／行動 Clash 用戶端，而電視只接 DHCP 到旁路由，由閘道負責 訂閱匯入之後的規則執行。
寫成文章時若只談其中一邊，讀者很容易在「我已經在路由上跑代理，為什麼 App 內行為還是怪」與「本機已開了 Stash，Wi‑Fi 卻還是直連」之間打轉。下面先假設您具備一組常見的機場 訂閱連結，並以規則模式為預設；接著分別說明在電視上操作 Stash 的注意點，以及旁路由上該與誰對齊（策略組、dns 區塊、透明代理與 fake-ip）。
2 tvOS 上的 Stash：與 iPhone 類似的「類 Clash」體驗
在 iPhone／iPad 上，Stash 已能相當貼合 Clash 家族的 YAML 語意：遠端訂閱匯入、proxy-groups、rules 與可選的 Rule Provider 都能在同一套邏輯下運作。大螢幕的 tvOS 路線在心智模型上可類比，差別主要在輸入法、遙控器操作、以及系統是否允許該 App 在電視上銷售或更新。若您已讀過站上的iPhone／iPad Stash 匯入 Clash 訂閱，可把該文當成「行動版流程」，而本文補上客廳場景下與 Netflix、旁路由的搭配。
與手機一樣，tvOS 上的代理軟體通常透過系統的 VPN 描述檔或 Network Extension 類 API 把符合條件的封包導入應用程式內部核心；因此您會看到「要開權限、要先選一份設定檔、再手動啟用連線」的標準路徑。重點在於：實際命中哪一條 Clash 分流規則、DNS 查詢是否與筆電一致、以及 Netflix 相關網域是否落在正確策略組。若本機只裝了 Stash 卻從未檢查規則前綴，症狀會像「有連上節點、App 內卻顯示錯誤區域或只載入封面」。
3 在 Apple TV 上匯入訂閱：從貼上連結到驗證策略組
實務步驟可依您實際畫面微調，但邏輯順序建議固定：先取得 HTTPS 的訂閱網址（與筆電 Clash 使用同一條，避免兩邊節點名稱不一致），在 Stash 的設定檔或訂閱頁面貼上並觸發更新；接著在 proxy-groups 裡確認 Netflix 專用或一般「串流」群組名稱與筆記一致。若供應商有獨立媒體節點，請在規則中讓 netflix.com、nflxvideo.net 等常見後綴優先指到該群組，避免落到預設的 select 或 url-test 出口。
匯入後不要只看「有節點列表」就關畫面：在電視上開啟連線日誌或等效面板，播放一段 Netflix 內容時觀察實際匹配規則與 SNI。若出現誤走 DIRECT 或 DNS 洩漏到電信商解析，優先回頭檢 dns 與 fake-ip-filter，其觀念可延伸閱讀 Meta 核心 DNS 防洩漏 一文，與大螢幕除錯同一套邏輯。遙控器輸入長網址不便時，可先在同一個家庭網段用手機產生 QR Code 或從筆電透過郵件傳遞，再於電視端掃描或從 iCloud 剪貼板同步，重點是訂閱匯入的網域必須與當初在桌面驗證時相同，避免兩套不同帳戶的 YAML。
4 旁路由當閘道：讓 Apple TV 不必「自己管代理」
第二條主軸是把 Apple TV 的「預設閘道」與「DNS」指到 旁路由：可以是 OpenWrt 上跑 Clash 或 Mihomo 的裝置、或一台 x86 軟路由、或群暉上 Docker 跑的閘道服務。實作重點在於 LAN 內的 DHCP 只發一個訊息出去：要嘛整屋都走旁路由，要嘛針對電視的 MAC 做保留位址，單獨只把該主機的閘道改成旁路 IP。這樣一來，tvOS 內的 App 不論是否內建代理，都會以為自己在「正常上網」，實際第一跳卻是閘道；閘道上的 Clash 分流再依 rules 決定要送哪個 策略組。
與 OpenWrt 透明代理或 群暉 Docker 閘道這類教學搭配時，您可以把旁路由想成「全屋的 Clash 執行器」。電視、遊戲主機、音響棒只要接同一個 VLAN 或 SSID，就能共享同一套訂閱匯入與日誌，維運成本比每台裝各裝一個客戶端低。缺點則是：若閘道掛了，全屋依賴它的裝置都會斷；因此仍建議主路由保留一條管理 SSID 直連外線，或預先寫好旁路掛掉時的故障排除流程。
透明轉送（REDIRECT、TUN、或 TProxy，依韌體與核心支援為準）在閘道側開啟後，內部終端往往不需要額外設定系統代理埠；但這也代表「規則寫錯就全家一起錯」。因此初期除錯建議從單一裝置、單一策略組驗證，再廣播到多裝置；並保留 SSH 到旁路本機的管道，避免被鎖在客廳畫面裡。
5 閘道上的 Netflix 與可維護的規則片段
不論是 Stash 本機或 旁路由，核心問題都是同一個：rules 陣列的順序與內容是否涵蓋 Netflix 的實際連線。多數社群規則集會以 DOMAIN-SUFFIX,netflix.com、DOMAIN-SUFFIX,nflxvideo.net 等條目搭配媒體專用 策略組；更完整的集合可透過 ACL4SSR 與 Rule Provider 方式引入，讓遠端清單與您的主設定檔分離、便於週期更新。請記得在 MATCH 前保留足夠精細的 DOMAIN／IP-CIDR 條目，避免一條寬鬆的 GEOIP 先截走串流。
下方 YAML 僅示範結構，實務上請把 PROXY 換成您真實的群組名稱，並依機場文件調整 netflix 專屬邏輯。若同時有本機 Stash 與閘道 Clash，兩邊的群組名稱建議盡量一致，減少「手機上選了 A 節點、客廳卻還在 B」的認知負擔。
proxy-groups:
- name: STREAM
type: select
proxies:
- 媒體節點-A
- 媒體節點-B
- 自動
rules:
- DOMAIN-SUFFIX,netflix.com,STREAM
- DOMAIN-SUFFIX,nflxvideo.net,STREAM
- DOMAIN-SUFFIX,netflix.net,STREAM
# 其餘規則與 MATCH…當 Clash 分流命中正確、畫面仍出現地區或 CDN 怪異，下一步多半是 DNS 與實際出口 IP 不一致：例如解析仍落在被限速的聯播網內。此時可配合 Sniffer 與 SNI 日誌（參考 HTTPS 嗅探與 SNI 分流）釐清「以為是 Netflix、其實先連到某個第三方網域」的狀況。長期仍應以可更新的 Rule Provider 維持網域清單，而不是一次性手抄。
6 DNS、觀看區域與日誌：大螢幕常見的「假斷線」
客廳觀影對延遲與抖動比瀏覽網頁更敏感。若 Apple TV 在路由器上同時指到兩套 DNS：一套是電信商自動下發、一套是您手動在 Stash 內指到 DoH，則實際解析可能分裂成「有時走內、有時走外」的夢靨。做法上建議在單一控制點收斂：要嘛讓 旁路由統一轉送 DNS 到 Clash 內的虛擬解析，要嘛在電視本機的 App 內關掉與系統衝突的解析器設定，兩邊擇一當作真相來源。FakeIP 與實體 IP 的差異在電視上特別難從畫面直覺判斷，所以務必學會從日誌讀關鍵欄位，而不是只看「有沒有顯示已連線」。
另一類症狀是帳戶層的：Netflix 在瀏覽器與在 App 內偵測的資訊不完全相同，機頂盒若曾快取舊的登入狀態，也會在切換節點後短暫顯示舊區。網路設定若已確認沒有雙重 NAT 或雙層代理打架，可再檢查是否同時在電視上開了本機 VPN、又在路由器上做了轉送，兩層同時改寫路由表時最難用直覺排除。
7 與 Android TV 路線的差異與可互參的站內文
若家裡同時有 Android TV 與 Apple TV，可以交叉閱讀站內的Android TV 盒與訂閱、串流教學：Google TV 一側往往更容易側載或安裝特定 APK，而 tvOS 則以 App Store 審核與系統權限較封閉聞名。兩邊的Clash 分流語意是通的，差別在安裝與更新渠道；旁路由方案則完全與作業系統無關，只要裝置能取得 DHCP 或靜態 IP 即可。您可以依家庭成員的技術背景選擇「每台電視自己跑 Stash」或「只維護一台閘道」。
在維持訂閱匯入品質上，也建議參考 Mihomo 訂閱拉取 403、User-Agent 與重定向排查，避免閘道主機在背景更新失敗、卻以為仍在使用新節點。整體而言，Apple TV、Stash 與旁路由的組合，是在 Apple 大螢幕生態內尋求「和桌面一樣可讀的 YAML 規則」時，一條可與 ACL4SSR、通用串流文並列的專線路徑，而不是單一技巧就能涵蓋所有帳戶與內容政策。
8 總結
要把 Netflix 在客廳跑順，Apple TV 使用者可優先釐清：要不要在 tvOS 內以 Stash 完成 訂閱匯入與本機 Clash 分流，或把責任丟給 旁路由上的閘道，讓全機只負責顯示畫面。兩者都要求策略組、DNS 與規則前綴彼此對齊，且最好與筆電使用同一邏輯的 YAML，以減少「同一帳戶、不同裝置卻出現不同觀看區域」的混亂。當您需要擴展網域清單或與團隊共用維運時，Rule Provider 與社群規則集能顯著降低手工維護成本。
相較尋找單一「最強節點」，可預測的規則命中與乾淨的 DNS 路徑往往更能改善大螢幕體感；若希望桌機、閘道與教學採用同一套主流用戶端體驗，從站內取得安裝包與圖形介面，再回頭對照本文與 旁路由設定，通常比在不同平台各用一種不兼容語意來得省力。
