你的telly IPTV代理真的安全嗎一份新手也能看懂的加固實戰指南【免費下載鏈接】tellyAn IPTV proxy項目地址: https://gitcode.com/gh_mirrors/te/telly先說個真實場景。上個月我幫一位朋友排查問題他折騰了整整一天Plex 始終找不到設備。我遠程一看配置文件里Base-Address 0.0.0.0:6077日志里還躺著一行刺眼的報錯。改成一個 IP 后三分鐘就通了。他撓著頭問我這玩意兒不是裝上就能用嗎怎么這么多講究telly 是一個用 Go 語言編寫的 IPTV 代理工具核心作用是把 IPTV 源的 M3U 播放列表翻譯成 Plex Live 能直接認出的虛擬電視調諧器。聽起來很酷但正因為它天生就要暴露在局域網上、還要替你去拉取各種流媒體源它的telly安全配置做得好不好直接決定了你的 IPTV 服務是只給你自己看還是全網免費共享。這篇文章不整那些讓人昏昏欲睡的安全理論就按風險從高到低的順序帶你把 telly 的每個薄弱點逐個焊死。全程有配置示例、有踩坑記錄跟著走一遍新手也能在半小時內搞定。先搞清楚 telly 把門開在哪里telly 的全部行為都由一個 TOML 配置文件控制默認放在三個位置之一/etc/telly/telly.config.toml、$HOME/.telly/telly.config.toml或者運行目錄下的telly.config.toml。官方示例配置可以看項目根目錄的README.md里面注釋寫得非常詳細建議當成字典來查。打開這個文件你會看到四個必填區塊[Discovery]telly 怎么向 Plex 自我介紹、[IPTV]流媒體行為、[Log]日志、[Web]網絡監聽。另外還有一個[[Source]]區塊用來配置你的 IPTV 源。記住這張地圖下面所有操作都是在這個文件上做文章。改動后重啟 telly 生效不需要重新編譯任何東西。第一站身份信息還在用出廠默認值先把它換掉telly 的[Discovery]區塊里有幾個字段是它向 Plex 證明我是我的憑證。官方示例里給出的默認值是[Discovery] Device-Auth telly123 Device-ID 12345678 Device-UUID 問題在于所有下載過這個項目的人手里的默認值都長得一模一樣。telly123這種密碼說句不好聽的跟沒鎖門沒什么區別。隔壁鄰居要是也裝了 Plex 和 telly兩邊設備直接互相認親你的頻道列表可能就跑到人家電視上去了。正確做法其實很樸素[Discovery] Device-Auth Kx9#mP2!vL5qR7 # 至少12位混合大小寫、數字和符號 Device-ID 8f3T2aB9 # 8位隨機字母數字別用12345678這種連續串 Device-UUID # 留空讓telly自動生成即可順手說個進階玩法如果你要跑兩個telly 實例比如給兩臺不同的 Plex 用Device-ID、Device-UUID和端口三者組合起來才是每臺設備的唯一鑰匙記得每個實例都換成不同組合不然兩臺會打架。這個細節寫在README.md的注釋里屬于資深用戶才懂的坑。第二站監聽地址設錯了等于把家門鑰匙掛門口這是整份配置里最容易出錯、也最危險的一環。先看兩個字段的分工Listen-Addresstelly 進程實際聽哪個網卡的哪個端口也就是真正開著的門Base-Addresstelly 告訴 Plex你來找我玩的時候用這個地址相當于遞給別人的名片不少教程會教你把兩個都設成0.0.0.0:6077然后你就收獲了和開頭那位朋友一模一樣的報錯。telly 在啟動時會對配置做檢查邏輯在main.go的validateConfig函數里發現Base-Address是0.0.0.0會直接拒絕啟動日志里寫著base URL is set to 0.0.0.0, this will not work.——因為 Plex 拿到這張名片會傻乎乎地往 localhost 上連而 localhost 是它自己不是你的 telly。更隱蔽的坑在反向搭配Listen-Address全接口監聽、Base-Address卻是 localhost這時 telly 只會甩給你一行警告然后照常運行。后果是什么局域網里任何設備都能直接訪問 telly 的 6077 端口而 Plex 卻連不上流。所以請記住這組黃金搭配[Web] Base-Address 192.168.1.100:6077 # 必須是telly所在機器的實際內網IP Listen-Address 0.0.0.0:6077 # 全接口監聽方便局域網設備發現如果你的 Plex 和 telly 在同一臺機器上Base-Address用localhost:6077也沒問題但一旦涉及局域網共享務必換成真實 IP。至于端口6077 只是約定俗成的默認值改成 8088、19000 之類的冷門端口能擋掉一大批只會掃默認端口的腳本小子。第三站配置文件本身就是你的保險柜聊完網絡說點很多人忽略的那份telly.config.toml里躺著什么你的 IPTV 服務商賬號密碼、M3U 播放列表的完整 URL——不少供應商的播放列表鏈接里直接內嵌username和password參數。也就是說這份文件本身就是一把萬能鑰匙。所以它的文件權限必須按保險柜標準來chmod 600 /etc/telly/telly.config.toml # 或者 chmod 600 ~/.telly/telly.config.toml600的含義是只有所有者能讀寫其他人一律靠邊站這對單用戶家庭環境是夠用的。如果你跟人合租服務器再狠一點把所屬組也鎖死別讓同組的其他用戶有可乘之機。有人可能要問那 M3U 地址里的密碼會出現在日志里嗎telly 這一點做得還算厚道——源碼里內置了一個凈化邏輯在lineup.go的getM3U和getXMLTV里會把日志中 URL 的username、password、token參數替換成REDACTED字樣再輸出。但注意日志凈化≠日志安全它只負責打碼不負責幫你隱藏其他敏感信息。還有一個容易踩的雷把[Log] Level調成debug時telly 啟動會把完整配置以 JSON 形式打印到日志里見main.go包括你的 Source 區塊。所以生產環境老老實實用infodebug 只留給本地調試。第四站日志和調試接口低調才能活得久接著上面說日志。[Log]區塊有兩個開關值得你認真權衡[Log] Level info # debug/info/warn/error/fatal 五檔可選 Requests false # 是否記錄每個HTTP請求Requests true的時候telly 會把每個訪問請求的客戶端 IP、User-Agent、路徑、耗時全部寫進日志代碼在routes.go的ginrus中間件。開發期開著確實方便排查但生產環境開著等于把自己家的訪客登記簿攤在門口。尤其當你把 telly 暴露到公網時這條建議從可選直接升級成必須——關掉它日志會安靜很多也少了很多被人研究的素材。另一個低調的秘訣telly 自帶一個/debug.json接口routes.go里注冊的會返回完整的頻道列表內部狀態。這玩意兒在本地調試時很香但如果你開了公網端口記得在反向代理或防火墻層面把它擋掉或者干脆別讓 telly 離開內網。順帶一提telly 還有一個/manage管理頁面前端代碼在frontend/目錄下默認沒有任何認證。誰連上你的 6077 端口誰就能看到這個頁面。所以再次強調防火墻只放行該放行的 IP別讓 6077 裸奔到公網。第五站用 Docker 部署這幾行配置能救命如果你用 Docker 跑 telly官方鏡像tellytv/telly:dev-ffmpeg自帶 ffmpeg 轉碼能力隔離性天然比裸進程好一截但有幾個細節值得摳一摳。最值得強調的就是配置文件的只讀掛載。想象一下配置文件能被容器里的進程改寫一旦某個環節出了岔子比如誤操作你的保險柜就可能被自己人撬開。改成只讀一勞永逸version: 3 services: telly: image: tellytv/telly:dev-ffmpeg container_name: telly ports: - 6077:6077 environment: - TZAsia/Shanghai volumes: - ./telly.config.toml:/etc/telly/telly.config.toml:ro # 關鍵就是末尾的:ro restart: unless-stoppedREADME.md里的 Docker 示例沒有加:ro但你完全可以加這不影響任何功能純賺一層保險。還有兩點官方兩個鏡像dev和dev-ffmpeg中dev-ffmpeg只多了個 ffmpeg體積大得有限建議無腦選它。萬一以后想開轉碼不用改任何啟動命令。注意[IPTV]區塊里的FFMpeg開關想用就取消注釋設為true不想用就保持注釋狀態千萬別寫成false——這會讓 telly 的解析邏輯陷入奇怪的狀態屬于 README 里明示的坑。關于 telly 還有個特色提醒它單實例加載超過 420 個頻道時Plex 會直接卡死lineup.go里寫死了這個上限超了直接 panic。所以老老實實用Filter正則把頻道過濾到合理數量比如Filter Sports|United States.*這既是性能問題也是安全問題的近親——頻道越少暴露面越小。收尾出門前的十分鐘自檢到這里核心的加固動作都做完了。最后送你一份出門檢查單每次改完配置重啟 telly 之前花十分鐘過一遍基本就穩了Device-Auth是不是還是telly123Device-ID還是不是12345678Base-Address填的是真實內網 IP而不是0.0.0.0配置文件權限是不是600Log Level是不是info級別Requests是不是false6077 端口有沒有被防火墻限制在可信 IP 范圍內有沒有打開/debug.json和/manage這類無認證接口的公網訪問Docker 掛載配置有沒有加:ro如果有一項打了勾但答案是沒做那就趁現在回去補上。安全這回事說穿了就是把默認值換掉、把暴露面收窄、把日志管住三件事。telly 的默認配置是為了讓你跑起來而不是為了讓你跑得安全——這兩者之間就差今天這幾步。最后啰嗦一句telly 處于活躍開發中配置項可能隨版本變動動手之前先瞄一眼README.md和更新日志。愿你的 telly 從此只為你自己亮燈把 IPTV 的樂趣留給客廳把麻煩擋在門外。【免費下載鏈接】tellyAn IPTV proxy項目地址: https://gitcode.com/gh_mirrors/te/telly創作聲明：本文部分內容由AI輔助生成（AIGC），僅供參考 你的telly IPTV代理真的安全嗎？一份新手也能看懂的加固實戰指南
你的telly IPTV代理真的安全嗎一份新手也能看懂的加固實戰指南【免費下載鏈接】tellyAn IPTV proxy項目地址: https://gitcode.com/gh_mirrors/te/telly先說個真實場景。上個月我幫一位朋友排查問題他折騰了整整一天Plex 始終找不到設備。我遠程一看配置文件里Base-Address 0.0.0.0:6077日志里還躺著一行刺眼的報錯。改成一個 IP 后三分鐘就通了。他撓著頭問我這玩意兒不是裝上就能用嗎怎么這么多講究telly 是一個用 Go 語言編寫的 IPTV 代理工具核心作用是把 IPTV 源的 M3U 播放列表翻譯成 Plex Live 能直接認出的虛擬電視調諧器。聽起來很酷但正因為它天生就要暴露在局域網上、還要替你去拉取各種流媒體源它的telly安全配置做得好不好直接決定了你的 IPTV 服務是只給你自己看還是全網免費共享。這篇文章不整那些讓人昏昏欲睡的安全理論就按風險從高到低的順序帶你把 telly 的每個薄弱點逐個焊死。全程有配置示例、有踩坑記錄跟著走一遍新手也能在半小時內搞定。先搞清楚 telly 把門開在哪里telly 的全部行為都由一個 TOML 配置文件控制默認放在三個位置之一/etc/telly/telly.config.toml、$HOME/.telly/telly.config.toml或者運行目錄下的telly.config.toml。官方示例配置可以看項目根目錄的README.md里面注釋寫得非常詳細建議當成字典來查。打開這個文件你會看到四個必填區塊[Discovery]telly 怎么向 Plex 自我介紹、[IPTV]流媒體行為、[Log]日志、[Web]網絡監聽。另外還有一個[[Source]]區塊用來配置你的 IPTV 源。記住這張地圖下面所有操作都是在這個文件上做文章。改動后重啟 telly 生效不需要重新編譯任何東西。第一站身份信息還在用出廠默認值先把它換掉telly 的[Discovery]區塊里有幾個字段是它向 Plex 證明我是我的憑證。官方示例里給出的默認值是[Discovery] Device-Auth telly123 Device-ID 12345678 Device-UUID 問題在于所有下載過這個項目的人手里的默認值都長得一模一樣。telly123這種密碼說句不好聽的跟沒鎖門沒什么區別。隔壁鄰居要是也裝了 Plex 和 telly兩邊設備直接互相認親你的頻道列表可能就跑到人家電視上去了。正確做法其實很樸素[Discovery] Device-Auth Kx9#mP2!vL5qR7 # 至少12位混合大小寫、數字和符號 Device-ID 8f3T2aB9 # 8位隨機字母數字別用12345678這種連續串 Device-UUID # 留空讓telly自動生成即可順手說個進階玩法如果你要跑兩個telly 實例比如給兩臺不同的 Plex 用Device-ID、Device-UUID和端口三者組合起來才是每臺設備的唯一鑰匙記得每個實例都換成不同組合不然兩臺會打架。這個細節寫在README.md的注釋里屬于資深用戶才懂的坑。第二站監聽地址設錯了等于把家門鑰匙掛門口這是整份配置里最容易出錯、也最危險的一環。先看兩個字段的分工Listen-Addresstelly 進程實際聽哪個網卡的哪個端口也就是真正開著的門Base-Addresstelly 告訴 Plex你來找我玩的時候用這個地址相當于遞給別人的名片不少教程會教你把兩個都設成0.0.0.0:6077然后你就收獲了和開頭那位朋友一模一樣的報錯。telly 在啟動時會對配置做檢查邏輯在main.go的validateConfig函數里發現Base-Address是0.0.0.0會直接拒絕啟動日志里寫著base URL is set to 0.0.0.0, this will not work.——因為 Plex 拿到這張名片會傻乎乎地往 localhost 上連而 localhost 是它自己不是你的 telly。更隱蔽的坑在反向搭配Listen-Address全接口監聽、Base-Address卻是 localhost這時 telly 只會甩給你一行警告然后照常運行。后果是什么局域網里任何設備都能直接訪問 telly 的 6077 端口而 Plex 卻連不上流。所以請記住這組黃金搭配[Web] Base-Address 192.168.1.100:6077 # 必須是telly所在機器的實際內網IP Listen-Address 0.0.0.0:6077 # 全接口監聽方便局域網設備發現如果你的 Plex 和 telly 在同一臺機器上Base-Address用localhost:6077也沒問題但一旦涉及局域網共享務必換成真實 IP。至于端口6077 只是約定俗成的默認值改成 8088、19000 之類的冷門端口能擋掉一大批只會掃默認端口的腳本小子。第三站配置文件本身就是你的保險柜聊完網絡說點很多人忽略的那份telly.config.toml里躺著什么你的 IPTV 服務商賬號密碼、M3U 播放列表的完整 URL——不少供應商的播放列表鏈接里直接內嵌username和password參數。也就是說這份文件本身就是一把萬能鑰匙。所以它的文件權限必須按保險柜標準來chmod 600 /etc/telly/telly.config.toml # 或者 chmod 600 ~/.telly/telly.config.toml600的含義是只有所有者能讀寫其他人一律靠邊站這對單用戶家庭環境是夠用的。如果你跟人合租服務器再狠一點把所屬組也鎖死別讓同組的其他用戶有可乘之機。有人可能要問那 M3U 地址里的密碼會出現在日志里嗎telly 這一點做得還算厚道——源碼里內置了一個凈化邏輯在lineup.go的getM3U和getXMLTV里會把日志中 URL 的username、password、token參數替換成REDACTED字樣再輸出。但注意日志凈化≠日志安全它只負責打碼不負責幫你隱藏其他敏感信息。還有一個容易踩的雷把[Log] Level調成debug時telly 啟動會把完整配置以 JSON 形式打印到日志里見main.go包括你的 Source 區塊。所以生產環境老老實實用infodebug 只留給本地調試。第四站日志和調試接口低調才能活得久接著上面說日志。[Log]區塊有兩個開關值得你認真權衡[Log] Level info # debug/info/warn/error/fatal 五檔可選 Requests false # 是否記錄每個HTTP請求Requests true的時候telly 會把每個訪問請求的客戶端 IP、User-Agent、路徑、耗時全部寫進日志代碼在routes.go的ginrus中間件。開發期開著確實方便排查但生產環境開著等于把自己家的訪客登記簿攤在門口。尤其當你把 telly 暴露到公網時這條建議從可選直接升級成必須——關掉它日志會安靜很多也少了很多被人研究的素材。另一個低調的秘訣telly 自帶一個/debug.json接口routes.go里注冊的會返回完整的頻道列表內部狀態。這玩意兒在本地調試時很香但如果你開了公網端口記得在反向代理或防火墻層面把它擋掉或者干脆別讓 telly 離開內網。順帶一提telly 還有一個/manage管理頁面前端代碼在frontend/目錄下默認沒有任何認證。誰連上你的 6077 端口誰就能看到這個頁面。所以再次強調防火墻只放行該放行的 IP別讓 6077 裸奔到公網。第五站用 Docker 部署這幾行配置能救命如果你用 Docker 跑 telly官方鏡像tellytv/telly:dev-ffmpeg自帶 ffmpeg 轉碼能力隔離性天然比裸進程好一截但有幾個細節值得摳一摳。最值得強調的就是配置文件的只讀掛載。想象一下配置文件能被容器里的進程改寫一旦某個環節出了岔子比如誤操作你的保險柜就可能被自己人撬開。改成只讀一勞永逸version: 3 services: telly: image: tellytv/telly:dev-ffmpeg container_name: telly ports: - 6077:6077 environment: - TZAsia/Shanghai volumes: - ./telly.config.toml:/etc/telly/telly.config.toml:ro # 關鍵就是末尾的:ro restart: unless-stoppedREADME.md里的 Docker 示例沒有加:ro但你完全可以加這不影響任何功能純賺一層保險。還有兩點官方兩個鏡像dev和dev-ffmpeg中dev-ffmpeg只多了個 ffmpeg體積大得有限建議無腦選它。萬一以后想開轉碼不用改任何啟動命令。注意[IPTV]區塊里的FFMpeg開關想用就取消注釋設為true不想用就保持注釋狀態千萬別寫成false——這會讓 telly 的解析邏輯陷入奇怪的狀態屬于 README 里明示的坑。關于 telly 還有個特色提醒它單實例加載超過 420 個頻道時Plex 會直接卡死lineup.go里寫死了這個上限超了直接 panic。所以老老實實用Filter正則把頻道過濾到合理數量比如Filter Sports|United States.*這既是性能問題也是安全問題的近親——頻道越少暴露面越小。收尾出門前的十分鐘自檢到這里核心的加固動作都做完了。最后送你一份出門檢查單每次改完配置重啟 telly 之前花十分鐘過一遍基本就穩了Device-Auth是不是還是telly123Device-ID還是不是12345678Base-Address填的是真實內網 IP而不是0.0.0.0配置文件權限是不是600Log Level是不是info級別Requests是不是false6077 端口有沒有被防火墻限制在可信 IP 范圍內有沒有打開/debug.json和/manage這類無認證接口的公網訪問Docker 掛載配置有沒有加:ro如果有一項打了勾但答案是沒做那就趁現在回去補上。安全這回事說穿了就是把默認值換掉、把暴露面收窄、把日志管住三件事。telly 的默認配置是為了讓你跑起來而不是為了讓你跑得安全——這兩者之間就差今天這幾步。最后啰嗦一句telly 處于活躍開發中配置項可能隨版本變動動手之前先瞄一眼README.md和更新日志。愿你的 telly 從此只為你自己亮燈把 IPTV 的樂趣留給客廳把麻煩擋在門外。【免費下載鏈接】tellyAn IPTV proxy項目地址: https://gitcode.com/gh_mirrors/te/telly創作聲明：本文部分內容由AI輔助生成（AIGC），僅供參考