从正向代理到反向代理，提升用户方观影体验。
Important
本教程面向正在使用他人 Emby 服务的普通观影用户，默认讨论 Direct Play / 直接播放场景。本文不教授 Emby 服务端搭建，也不展开转码、硬解或 FFmpeg 调优。
同一个 Emby，有人播放流畅，有人频繁缓冲；同一个入口，白天正常，晚高峰却很慢；有时源站直连不理想，换一个代理节点或备用入口后就恢复了。出现这些差异，并不一定意味着 Emby 服务器坏了。很多时候，问题出在用户与 Emby 之间的访问路径。
本指南重点讨论普通用户能够调整的内容：入口选择、线路测试、正向代理、反向代理和规则分流。不管使用正向代理还是反向代理，最终目标都只有一个：提升用户方的 Emby 观影体验。
- 1. 本文讨论什么，不讨论什么
- 2. 为什么国外 Emby 会卡
- 3. 正向代理：用户自己选择一条更好的路
- 4. 反向代理：在用户和 Emby 之间增加一个入口
- 5. STRM / 直链型 Emby 的反代局限
- 6. 多入口、Cloudflare、VPS 反代应该怎么理解
- 7. 正向代理和反向代理怎么配合
- 8. 如何测试哪个入口更适合自己
- 9. 常见误区与最终结论
- 附录与规则示例
- 参考资料
- 免责声明
本文讨论的是这样一种常见场景：你正在使用别人已经搭建好的 Emby，源站大多位于国外，并且服务方已经提供公网访问地址。服务方可能同时给出源站直连、Cloudflare、VPS 反代、地区优化、备用或负载均衡等多个入口。
本文默认讨论以 Direct Play / 直接播放 为主的观影场景。
按照 Emby 官方文档，常见播放方式可以简单理解为：
- Direct Play / 直接播放：文件基本不经修改，直接交给客户端播放。
- Direct Stream / 直接串流：通常不重新编码视频，但可能重新封装容器，或处理音轨、字幕。
- Transcode / 转码：服务器实时把视频转换成客户端可以播放的格式。
直接播放通常不需要服务器实时解码、修改和重新编码视频，因此更有利于减少服务器转码压力。Emby 的转码说明也指出，应用会在可能的情况下直接播放文件，只有在格式、码率或字幕等条件不兼容时才使用转码。
但请注意：本文不重点讨论 Emby 转码。
原因很简单：本文面向的是使用别人 Emby 服务的用户，而不是服务端管理员。CPU 转码、GPU 硬件加速、HDR Tone Mapping、字幕烧录、FFmpeg 参数和服务端码率限制，都不是普通用户能够直接控制的主线问题。如果视频因客户端兼容性、字幕格式或音轨格式而触发转码，那属于“服务端性能与客户端兼容性”主题，不纳入本文展开。
本文也不讨论：
- 如何从零搭建 Emby；
- 家宽有没有公网 IP；
- 如何做内网穿透；
- 如何开放源站端口；
- 如何配置服务器硬解；
- 如何压制视频或调整转码参数。
本文只研究一件事：作为观影用户，怎样找到一条更适合自己的访问路径。
播放国外 Emby，可以想象成从家里向一座海外仓库持续取货。真正的网络路径通常不是一条笔直的线，而是要经过本地 Wi-Fi、宽带运营商、跨境出口、国际骨干网和海外机房。
典型路径可以简化为：
用户设备 → 家庭网络 → 运营商 → 跨境链路 → 海外机房 → Emby
其中任何一段都可能影响体验：
- 家庭 Wi-Fi 信号不稳，电视与路由器之间就可能丢包；
- 运营商到某个海外网络的互联质量不好，路径可能绕远；
- 跨境链路在晚高峰拥塞，可用带宽会明显下降；
- 海外机房到中国方向的线路不理想，Ping 看起来还行，持续下载却不稳定；
- Emby 源站本身负载过高，也可能导致海报慢、起播慢或播放中断。
因此，看到卡顿时，不要马上得出“Emby 服务坏了”的结论。可以先观察现象：
- 海报加载慢：可能是入口响应、DNS、API 请求或小文件连接效率不理想。
- 起播慢：可能是建立连接、鉴权、视频首段读取或跳转较慢。
- 播放一段时间后缓冲：更像是持续带宽或稳定性不足。
- 拖动进度条后长时间不恢复：可能是新范围请求、上游读取或直链跳转响应慢。
- 只有晚高峰卡：通常更值得怀疑线路拥塞，而不是固定配置错误。
Ping 主要反映一次小数据包往返所需的时间。视频播放却需要在较长时间内持续传输大量数据。
一条线路可能只有 60 ms 延迟，但下载速度忽高忽低；另一条线路可能有 130 ms 延迟，却能稳定传输高码率视频。对观影而言，后者反而可能更舒服。
可以把它理解为：
延迟像“第一辆车多久到达”，播放稳定性则更像“后面的货车能不能连续不断地到达”。
因此，延迟是参考值，不是最终答案。
图 1：用户到国外 Emby 之间可能出现绕路、拥塞和丢包。
正向代理的核心是 用户侧选路。
最通俗的理解是：
用户不直接去 Emby，而是自己选择一个代理节点，让节点代替自己去访问 Emby。
典型路径是：
用户 → 正向代理节点 → Emby 入口或 Emby 源站
常见工具包括 Clash、Mihomo、OpenClash、Shadowrocket、Loon、Quantumult X、Surge、Stash，以及路由器上的透明代理。
如果用户直连 Emby 的跨境路径不理想，而某个代理节点与用户、Emby 两端的互联都比较好，那么代理节点就像换乘站，可以绕开原来拥塞或绕路的一段。
不过这不是保证。节点也可能带宽不足、晚高峰拥塞，或者到 Emby 的回程线路很差。因此，不能因为某个节点名称里写着“专线”“高速”或“流媒体”，就默认它一定适合 Emby。
最终仍要用真实影片测试。
图 2：正向代理由用户选择出口线路。
更推荐的做法，是只让 Emby 相关域名进入专用策略组：
Emby 域名 →
🎥 Emby策略组 → 手动选择或测试合适节点
这样做有几个好处：
- 不影响其他网站和应用的访问路径；
- 更容易比较不同节点的 Emby 表现；
- 出现问题时更容易判断是不是 Emby 分流规则造成的；
- 可以针对不同 Emby 域名选择不同线路。
Mihomo 路由规则文档说明，DOMAIN 用于匹配完整域名，DOMAIN-SUFFIX 用于匹配域名及其子域名，规则通常从上到下匹配。OpenClash 也支持在订阅配置之上加入自定义规则。正文不需要记住所有语法，只需要记住核心逻辑：
当访问指定的 Emby 域名时，把连接交给 Emby 策略组。
最小规则示例统一放在附录 A。
如果只使用一个 Emby 地址，手工添加一条域名规则就足够了。如果你有多个 Emby 服务，或者还需要维护海报域名、直链域名和备用入口，规则就可能越来越多。
这时可以使用类似 Cyclince/Private-rules 的私有规则控制台，把自定义域名、关键词、IP 或远程订阅集中维护，再输出 YAML、LIST、TXT 或 JSON 等格式。项目当前说明中列出的适用客户端包括 Mihomo、Clash、OpenClash、Stash、Loon、Surge 和 Shadowrocket 等。
Private-rules 只是生态案例，不是必选项。你也可以维护自己的文本文件，或参考 blackmatrix7/ios_rule_script 等多客户端规则项目的目录组织方式。
需要注意：
- 私有订阅地址可能包含个人服务域名，不要公开传播；
- Token 只是访问控制手段，不代表内容经过加密；
- 不同客户端的规则格式并不完全相同；
- 规则更新后要确认客户端已经成功刷新；
- 如果播放发生 302 跳转，只有 Emby 入口域名可能还不够。
正向代理不能解决所有问题。如果源站服务器已经过载、影片文件损坏、账号权限异常、网盘限速或直链失效，换再多代理节点也不一定有用。
反向代理的核心是 增加一个中间入口。
可以把它理解为：
用户先访问一个中转窗口，再由这个窗口访问 Emby，并把 Emby 的响应返回给用户。
典型路径是：
用户 → 反代入口 → Emby
按照 NGINX 官方说明，反向代理会接收客户端请求、转发给上游服务器，再把上游响应交还给客户端。Caddy 也可以承担相同角色。
反代入口可能由以下方式实现：
- VPS 上的 NGINX 或 Caddy；
- Nginx Proxy Manager 等图形化面板；
- Emby 专用反代管理面板；
- Cloudflare 代理；
- Cloudflare Worker；
- 地区优化或负载均衡入口。
图 3：反代入口位于用户与 Emby 之间。
服务方可以配置反向代理，为所有用户提供源站、Cloudflare、VPS 或地区优化等不同入口。
用户自己也可以在 VPS 或 Cloudflare Worker 上增加中间入口，但这里有一个非常重要的前提：
Warning
必须先确认服务方是否允许第三方反代，并遵守服务方的使用要求。未经允许，不应公开、共享或商业化第三方反代入口。
原因包括：
- 反代可能改变服务方看到的访问 IP；
- 错误配置可能让多个用户看起来来自同一个地址；
- 反代日志可能记录账号 Token、API Key 或带鉴权参数的 URL；
- 某些服务明确禁止共享、转发、改写或二次提供入口；
- 反代可能增加源站连接数或带宽压力；
- 未经允许公开反代地址，可能给服务方和其他用户带来安全风险。
所以，“技术上可以”不等于“服务规则允许”。本文介绍用户自建反代，是为了解释网络路径和生态方案，不代表鼓励绕过服务方限制。
VPS 反代至少包含两段网络：
- 用户 → VPS；
- VPS → Emby。
只有两段都比较稳定，整体体验才可能改善。假如用户到 VPS 很快，但 VPS 到 Emby 很慢，播放仍然会卡；反过来也一样。
因此，VPS 的地区、运营商互联、带宽、流量限制、晚高峰表现和到 Emby 的线路都很重要。VPS 反代不是天然更快，也不是天然更稳。
hkfires/EmbyProxy 是一个用于管理和转发 Emby 节点请求的开源项目。其当前 README 提到 Web 管理界面、多节点配置、统一代理入口、节点独立密钥、在线检测、运行状态与播放统计等能力。
它适合用来说明：如果用户或维护者需要在一台 VPS 上集中管理多个 Emby 入口，可以使用专用面板减少重复配置。
它不是唯一方案，但可以算是对新手较为友好的项目，只需要在统一管理的面板上进行操作即可。普通 NGINX、Caddy，以及 Nginx Proxy Manager 等通用工具也可以提供反向代理入口。选择面板只影响管理方式，不直接决定线路质量。
Cloudflare 开启代理后，HTTP/HTTPS 流量会先进入 Cloudflare 网络，再前往源站。Cloudflare Proxy Status 对此有明确说明。
Cloudflare Worker 则可以在边缘处理请求，并通过 fetch 等方式访问上游。Emby 生态中可以看到多种实现思路，例如：
- MakkaPakka 的反代面板：多节点分流与反向代理管理面板，通过将 Cloudflare Workers 与 D1 数据库相结合，并在面板内置CF优选测试工具，实现了媒体服务器网络层面的“智能调度”。
- chenhr454/emby---worker：也是基于 Workers 与 D1 的 Emby 反代和节点管理案例；其仓库说明 GitHub 已暂停更新，最新内容转移到 Telegram，使用前要特别核对维护状态。
- 通用 Workers 反代项目，如 ymyuuu/Cloudflare-Workers-Proxy：可帮助理解“把一个网址映射到另一个网址”的通用思路，但不是 Emby 专用保证。
这些项目都只是生态案例，不是唯一推荐，也不代表部署后一定适合视频流量。
Cloudflare 官方明确说明，Anycast 请求不一定进入地理位置最近的数据中心，互联网互联关系、拥塞与可靠性策略都会影响路径。因此，Cloudflare 入口可能改善某些网络，也可能与直连相近，甚至更慢。Cloudflare 地理路由说明对此有直接说明。
此外，Cloudflare 对 Workers 有账户和平台限制，对视频交付也有专门的产品与政策说明。使用前应查看最新的 Workers Limits 与 Cloudflare 视频交付说明，不能把免费 Worker 或普通 CDN 视为无限制的视频中转服务。
Cloudflare 使用共享的 Anycast 地址。社区中的“优选 IP”通常是从可用地址中测试延迟、丢包和下载速度，再选择在当前网络中表现较好的地址。
XIU2/CloudflareSpeedTest 是常见的测速工具案例。它不只测延迟，也会测试丢包和下载速度；项目本身也提醒使用者注意代理套 CDN 的风险。
需要特别强调：
- 优选 IP 不是 Cloudflare 官方承诺的永久加速功能；
- 今天表现好的 IP，晚高峰或换一个运营商后可能不同；
- IP 测速结果好，不代表完整的 Emby 播放链路一定好；
- 域名、TLS 证书、SNI 和 Host 等关系配置错误，可能导致连接失败；
- 最终仍要用真实 Emby 入口和真实影片测试。
反向代理并不适合所有 Emby 形态。最容易被误解的，就是网盘 STRM / 直链型 Emby。
在本地存储型 Emby 中，视频文件通常位于 Emby 服务器或服务器可直接读取的存储中。播放时，视频数据往往由 Emby 服务器发送给客户端。这种情况下，用户到 Emby 入口的线路通常直接影响视频播放。
而在 STRM 场景中，.strm 文件可能只保存一个网络资源 URL。Emby STRM 文档明确说明，STRM 文件可以包含互联网视频流的直接链接或共享媒体路径。
这类 Emby 可能主要负责：
- 媒体库管理；
- 海报与刮削展示；
- 用户鉴权；
- 提供播放入口；
- 返回 STRM、302 跳转或远程直链。
真正的视频内容却可能来自：
- 网盘；
- 对象存储；
- OpenList / AList 等文件入口；
- 第三方直链；
- 其他远程文件系统。
图 4：Emby 可能只提供鉴权与资源地址，真正视频流来自网盘。
最重要的一句话是：
如果 Emby 只是负责告诉你去哪里拿视频，而视频本身来自网盘，那么优化 Emby 入口，不一定等于优化视频下载路径。
假设用户通过 VPS 反代访问 Emby：
用户 → VPS 反代 → Emby
登录、海报和媒体库请求会经过 VPS，因此界面可能变快。但点击播放后，Emby 返回一个网盘直链，客户端随后直接访问网盘：
用户 → 网盘或第三方直链
此时 VPS 不在真实视频流路径中。即使 Emby 入口速度很好，网盘限速、直链质量或用户到网盘的线路仍然可能造成缓冲。
这时优化重点可能变成：
- 用户到网盘资源的线路；
- 网盘或对象存储的限速策略；
- 302 跳转后的目标域名；
- 客户端是否直接连接资源；
- 直链是否频繁过期；
- STRM 实际指向的域名是否需要单独分流；
- 网盘入口在白天与晚高峰的持续下载表现。
如果你只为 emby.example.com 添加代理规则，而视频最终跳转到 drive.example.net，后者不会自动遵循前者的域名规则。是否需要给资源域名单独分流，要根据实际播放路径、服务方说明和使用许可决定。
即使不能改变真实视频流，反代仍可能改善登录、媒体库浏览、海报加载或鉴权稳定性。因此不能简单说“STRM 反代完全没用”，更准确的说法是：
STRM / 直链型 Emby 中，反代对真实视频播放的改善可能有限，必须先确认视频数据究竟经过哪里。
服务方提供多个入口，本质上是在给用户提供不同的访问路径，而不是让用户判断哪个名称听起来更高级。
常见入口包括：
| 入口类型 | 可以怎样理解 | 可能的优势 | 可能的局限 |
|---|---|---|---|
| 源站直连 | 用户直接访问 Emby | 路径简单、排错方便 | 跨境线路可能不理想 |
| Cloudflare 入口 | 先进入 Cloudflare 网络 | 某些网络下接入更稳定 | 不保证更快，受路由和平台规则影响 |
| VPS 入口 | 经一台中转服务器访问 | 路径可控、便于定向优化 | 两段线路任一不佳都会拖慢 |
| 地区优化入口 | 针对某些地区或运营商设计 | 可能更适合特定用户 | 换地区或运营商后未必有效 |
| 备用入口 | 主入口异常时切换 | 提高可用性 | 平时不一定比主入口快 |
| 负载均衡入口 | 在多个上游之间分配请求 | 可分散故障或负载 | 调度结果未必最适合每个用户 |
图 5：不同入口最终可能指向同一 Emby，但中间路径不同。
建议从最简单的路径开始：
- 先测试服务方推荐的默认入口；
- 再测试源站直连和其他官方入口；
- 仍不理想时，再尝试给指定入口使用正向代理；
- 只有在服务方允许、并且确实有需求时，才考虑自己的 VPS 或 Worker 入口；
- 每次只改变一个变量，避免最后不知道究竟是哪一层起作用。
正向代理与反向代理不是互斥关系，也不是谁替代谁。
- 正向代理优化的是 用户出口路径；
- 反向代理优化的是 中间入口路径。
两者组合时，路径可能是：
用户 → 正向代理节点 → 反代入口 → Emby
图 6：正向代理优化用户出口，反向代理优化中间入口。
例如，服务方提供了一个 VPS 反代入口，但用户直连该 VPS 的线路不理想；某个代理节点访问这个入口却很稳定。这时让 Emby 域名经代理节点访问反代入口，可能得到更好的体验。
每增加一层，都可能增加新的问题：
- DNS 解析与规则命中错误；
- TLS、证书、SNI 或 Host 不匹配；
- 某一层带宽不足；
- 某一层连接超时；
- WebSocket 或范围请求处理不正确；
- 日志暴露敏感鉴权参数；
- 排错时无法判断是哪一层出现故障。
所以不要默认“多套几层代理一定更稳”。正确方法是逐层验证：
- 先测直连入口；
- 再测只使用正向代理；
- 再测只使用反代入口；
- 最后才测试正向代理与反代组合；
- 如果组合没有明显收益，就回到更简单的路径。
线路选择不能只靠一次 Ping 或测速截图。最可靠的方法，是在尽量相同的条件下做对照播放测试。
图 7：固定环境、逐个入口测试，并在晚高峰复测。
尽量保持以下条件不变：
- 同一台设备；
- 同一个 Emby 客户端；
- 同一个家庭宽带或移动网络；
- 同一部影片；
- 同一音轨、字幕和清晰度；
- 尽量确认播放方式一致。
如果一会儿用电视 Wi-Fi，一会儿用手机 5G，一会儿又换了播放器，那么结果很难直接比较。
建议选择一部自己有权限播放、时长较长、码率相对较高的影片。过低码率的视频对网络要求太小，可能无法暴露线路差异。
本文仍默认直接播放场景。如果某个入口下客户端突然开始转码，应先记录下来，因为这已经不只是网络路径变量。
每个入口至少观察：
- 媒体库和海报是否能正常加载；
- 点击播放后多久出现画面；
- 播放 10 至 20 分钟是否缓冲；
- 向前拖动数次后多久恢复；
- 高码率片段是否持续稳定；
- 连续播放下一集是否中断；
- 客户端是否频繁报网络错误。
跨境线路的白天表现和晚高峰表现可能差别很大。白天测一次只能说明当时可用，不能代表晚上也稳定。
建议至少保留一组晚高峰测试结果。如果某个入口白天极快、晚上频繁缓冲，而另一个入口全天速度不算最高却很稳定，通常应该选择后者。
如果服务属于 STRM / 直链型，测试时还要关注：
- 播放后是否跳转到其他域名；
- 视频是否由网盘或对象存储直接提供；
- 只有海报快，还是视频也确实更稳；
- Emby 域名规则是否覆盖了实际资源域名。
不熟悉抓包的用户不必强行研究复杂工具。可以先向服务方确认服务类型，或查看客户端调试信息、播放 URL 域名和服务方提供的线路说明。
不需要追求精确到毫秒。用“快、一般、慢”“无缓冲、偶尔缓冲、频繁缓冲”记录，也比只看一次 Ping 更有意义。
不一定。视频播放更依赖持续带宽、丢包、抖动和稳定性。低延迟只能说明连接响应较快。
不一定。Cloudflare 的接入点和回源路径会受到运营商互联、网络拥塞和调度策略影响。必须在自己的网络中实测。
不一定。VPS 反代同时依赖“用户到 VPS”和“VPS 到 Emby”两段线路，任何一段不理想都会影响整体体验。
不对。服务方和用户都可以配置反代入口，但用户必须先取得服务方允许，并遵守服务规则、平台条款和当地法律法规。
不对。每增加一层都会增加故障点和排错难度。只有在对照测试证明确有收益时，才值得保留组合路径。
不能。它无法修复源站过载、资源损坏、账号权限、网盘限速或失效直链。
不对。多个入口只是多条路径。用户只需要选择最适合自己的一条，不需要把所有入口都配置上。
不一定。真实视频流可能来自网盘或第三方直链，Emby 入口只负责鉴权、海报和跳转。
不管是正向代理还是反向代理，最终目标都只有一个：提升用户方的 Emby 观影体验。
可以把全文归纳成三个步骤：
- 先测试入口：比较服务方提供的源站、Cloudflare、VPS、地区和备用入口。
- 再优化路径：需要时给 Emby 单独使用正向代理，或在获得允许后测试反代入口。
- 最后看真实播放：不要只看 Ping，要看起播、拖动、高码率稳定性、晚高峰和连续播放。
先测试入口，再优化路径，最后以真实播放体验为准。
以下只展示最小思路，不是完整配置文件。请先确保客户端中已经存在名为 🎥 Emby 的策略组，并根据当前客户端版本核对语法。
rules:
- DOMAIN,emby.example.com,🎥 Emby
- MATCH,漏网之鱼如果需要匹配主域名及其子域名，可以根据实际地址使用 DOMAIN-SUFFIX。Mihomo 的规则顺序通常从上到下，因此 Emby 专用规则应放在兜底规则之前。
DOMAIN,emby.example.com,🎥 Emby
FINAL,DIRECT
DOMAIN,emby.example.com,🎥 Emby
FINAL,漏网之鱼
HOST,emby.example.com,🎥 Emby
FINAL,DIRECT
不同软件的规则名称、配置区段和兜底策略有所区别，但核心逻辑相同：
Emby 域名 → Emby 策略组。
如果视频会跳转到网盘或直链域名，还需要先确认服务方是否允许，并判断真实资源域名是否应单独分流。
Private-rules 可以用来维护个人 Emby 域名、IP、关键词和远程规则来源，并按不同格式输出订阅。它适合以下用户：
- Emby 地址较多；
- 需要长期维护规则；
- 不希望把私人域名放进公开规则仓库；
- 需要把同一批规则分发给多个客户端。
它只是案例，不是唯一方案。使用时要保护后台密码、会话密钥和私密订阅 Token。
EmbyProxy 可作为多 Emby 节点反代管理面板案例，用于集中维护节点、上游地址、访问密钥、运行状态和播放统计。
它更适合确实需要集中维护多个入口的用户或维护者。只有一个入口时，简单的 NGINX 或 Caddy 配置可能更容易排错。无论使用什么工具，都必须遵守 Emby 服务方要求，不得未经允许公开或共享反代入口。
Cloudflare Worker 可以作为一个中间入口，将请求转发到已有 Emby 地址。社区方案可能结合自定义域名、Workers、优选 IP、节点管理或访问统计。
可参考的生态案例包括：
- MakkaPakka 的反代面板：适用于 Emby/Jellyfin 的多节点分流与反向代理管理面板；
- chenhr454/emby---worker：Emby 专用 Worker 与 D1 管理案例；
- ymyuuu/Cloudflare-Workers-Proxy：通用 Workers 反向代理案例；
- XIU2/CloudflareSpeedTest：CF 地址延迟、丢包和下载速度测试案例；
- Cloudflare 官方 Speed Test 组件：用于理解网络质量不只包含延迟。
这些方案不能证明 Cloudflare 一定更快，也不能替代对服务条款、Workers 限制和视频流量政策的核对。
- Emby：Direct Play、Direct Stream 与 Transcoding
- Emby：Transcoding
- Emby：System Requirements
- Emby：STRM Files
- Mihomo：Route Rules
- Mihomo：Rule Providers
- OpenClash：配置文件说明
- OpenClash：规则设置
- Quantumult X 官方示例仓库
- Loon Manual
- Cyclince/Private-rules
- blackmatrix7/ios_rule_script
- NGINX：Reverse Proxy
- Caddy：Reverse Proxy Quick Start
- Jellyfin：Reverse Proxy
- Jellyfin：NGINX Reverse Proxy
- hkfires/EmbyProxy
- Nginx Proxy Manager
- Cloudflare：Proxy Status
- Cloudflare：How Cloudflare Works
- Cloudflare：Geographic Traffic Routing
- Cloudflare：Workers Limits
- Cloudflare：Delivering Videos with Cloudflare
- Cloudflare：Cloudflare IP Addresses
- cloudflare/speedtest
- XIU2/CloudflareSpeedTest
- chenhr454/emby---worker
- ymyuuu/Cloudflare-Workers-Proxy
- MakkaPakka Telegram 参考帖
本文仅用于网络路径、代理概念与 Emby 观影体验优化的学习交流，不构成对任何代理服务、VPS、Cloudflare 产品、开源项目或 Emby 服务的商业推荐、性能保证或可用性承诺。
文中资料、项目链接和技术说明均整理自互联网公开信息，包括官方文档、公开 GitHub 仓库、项目 README 与公开教程。相关名称、商标、代码、文档和项目权利归各自权利人所有。本文不会为不可访问或无法核实的教程内容编造具体操作步骤。
读者在使用正向代理、反向代理、Cloudflare Worker、VPS、优选 IP 或第三方规则项目前，应自行确认并遵守：
- 所在国家或地区的法律法规；
- Emby 服务提供方的使用要求；
- 代理节点或网络服务提供方的服务条款；
- Cloudflare 等平台的最新套餐限制和可接受使用政策；
- 开源项目的许可证、安全说明和维护状态；
- 网盘、对象存储与内容提供方的访问、带宽和版权规则。
未经 Emby 服务方明确允许，不应擅自建立、公开、分享或商业化第三方反代入口，也不应绕过账号限制、访问控制、流量限制或内容授权。
网络质量会随地区、运营商、时间、入口负载和上游路由变化。本文提到的任何入口、节点、反代或优选结果，都需要以使用者自己的真实播放测试为准。因配置错误、账号泄露、服务中断、平台封禁、流量费用或其他使用后果造成的损失，应由实际操作人员自行承担。