👉 “它们在监控系统眼里长什么样”。 一、先给你一个总览结论 协议 在 DPI 眼里像什么 REALITY 「某个真实网站 + 某个真实浏览器」 TUIC 「正常的 HTTP/3 / QUIC 网站访问」 Hysteria 2 「高随机、异常但难以归类的 UDP 流量」 一句话总结： REALITY = 隐身 TUIC = 混在主流里 HY = 硬抗干扰 下面展开说 👇 二、REALITY：DPI 眼里的“完美伪装者” 🔍 DPI 看到的是什么？ 标准 TLS ClientHello 正常的： SNI ALPN Cipher Suites 指纹与真实浏览器高度一致 访问的域名本身是真实存在的网站 👉 从统计、行为、语义上都“合理” 🧠 DPI 的判断结果 看起来就是： 「某个用户在访问某个正常 HTTPS 网站」 无法通过协议特征判断 主动探测风险极高（可能直接探测到真实网站） 🚨 封锁成本 封它 = 误伤真实网站 封它 = 误伤真实浏览器指纹 📌 这是目前 DPI 最不愿意碰的一类流量 三、TUIC：DPI 眼里的“QUIC 主流用户” 🔍 DPI 看到的是什么？ UDP QUIC 握手 行为模式非常接近： HTTP/3 Chrome / Edge 访问网站 但注意一点 👇 它不像 HTTPS 那么“完美”，而是： 「看起来像一个 QUIC 应用，但不一定是网页」 🧠 DPI 的判断结果 协议上：合法 行为上：偏重度 用途上：不完全确定 👉 DPI 会给它打一个标签： “QUIC 高流量应用” 🚨 封锁成本 精准封 TUIC：困难 粗暴封 UDP / QUIC： 会影响 HTTP/3 会影响大量正常网站 📌 所以 TUIC 通常“混在一大堆正常 QUIC 流量里活着” 四、Hysteria 2：DPI 眼里的“异常但不好杀的东西” 🔍 DPI 看到的是什么？ UDP 高度随机化的数据包 包大小、发送间隔变化大 不像： TLS QUIC HTTP 任何主流应用 👉 在 DPI 眼里，它更像： 「某种自定义 UDP 协议」 🧠 DPI 的判断结果 识别为“异常流量”的概率很高 但： 没有稳定指纹 不好写规则精准识别 更像是： 游戏加速器 / P2P / 专有实时协议 🚨 封锁成本 精准封：难（变化太多） 粗暴封 UDP： 影响游戏、视频会议、实时通信 更常见的对策是： 限速 丢包 抖动 📌 HY 的策略不是“不被发现”，而是“发现了也不好处理” 五、把三者放在一起对比（核心差异） 维度 REALITY TUIC Hysteria…

Cloudflare CLI 一般指的是 wrangler，这是 Cloudflare 官方提供的命令行工具，用来管理和开发 Cloudflare 平台上的各种服务，尤其是 Cloudflare Workers。 一、Cloudflare CLI 是什么？ Wrangler 是 Cloudflare 的官方 CLI（Command Line Interface），主要用于： 开发、测试、部署 Cloudflare Workers 管理 Pages、R2、KV、D1、Queues、Durable Objects 与 Cloudflare 账号和项目进行交互 一句话概括： Wrangler = Cloudflare 平台的开发与运维入口 二、能做什么？（核心功能） 1️⃣ Workers（最常用） 创建 Workers 项目 本地开发与调试 一键部署到全球边缘节点 wrangler init my-worker wrangler dev wrangler deploy 2️⃣ Cloudflare Pages 用于前端项目（如 React / Vue / Next.js）部署： wrangler pages dev wrangler pages deploy 3️⃣ KV（键值存储） 适合缓存、配置、小数据存储： wrangler kv:namespace create my_kv wrangler kv:key put --binding=MY_KV hello world 4️⃣ R2（对象存储，类似 S3） 存文件、图片、备份 无出口流量费 wrangler r2 bucket create my-bucket wrangler r2 object put my-bucket/file.txt ./file.txt 5️⃣ D1（Serverless SQLite） Cloudflare 的托管 SQLite 数据库 非常适合轻量后端 wrangler d1 create my-db wrangler d1 execute my-db --command "SELECT 1" 6️⃣ Durable Objects 有状态服务 适合聊天室、协作应用、游戏房间 Wrangler 用于创建、绑定和迁移 Durable Objects。 三、安装方式 前置条件 Node.js ≥ 16（推荐 LTS） 安装 npm install -g wrangler 或使用 pnpm / yarn： pnpm add -g wrangler yarn global add wrangler 验证： wrangler --version 四、登录与配置 wrangler login 会自动打开浏览器完成 OAuth 授权。 项目核心配置文件是： wrangler.toml 示例： name = "my-worker" main = "src/index.ts" compatibility_date = "2024-01-01" [[kv_namespaces]] binding = "MY_KV" id = "xxxxxxxx" 五、适合哪些人用？ 非常适合： 🧑‍💻…

通用订阅 Stash Mihomo Egern Surfboard Surge Surge(macOS) Loon Shadowrocket Quantumult X sing-box V2Ray URI JSON

这是 服务器风扇的正常现象，比如我们在使用的 Dell PowerEdge R250 这种 1U 机型。 你看到 30% 转速就达到 5700 RPM，其实完全符合 1U 服务器的设计逻辑。 下面我解释原因👇 ✅ 1U 服务器风扇为什么 RPM 高得惊人？ 原因 1：风扇小，但需要极高风量（CFM） Dell R250 是 1U 机架式服务器，高度非常薄，只能使用： 40mm 或 60mm 小尺寸高速风扇 风扇直径小 → 需要更高转速才能推动足够空气通过狭窄的散热通道。 这类风扇的正常满速RPM一般是： 10000–20000 RPM（完全正常） 所以 5700 RPM 仅仅相当于中低速。 ✅ 原因 2：服务器要保持风冷通道压力（Static Pressure） 服务器内部风道狭窄，需要高静压把风强制吹过： CPU 散热片 内存条 主板 VRM RAID 卡 / 网卡 电源模块 普通家用 PC 的风扇不需要这么大的静压。 ✅ 原因 3：BIOS / iDRAC 的安全策略使风扇默认高速运行 戴尔服务器默认风扇策略是： 即使低负载也要维持较高风量 防止任何硬件位置出现热点 即使你觉得“浪费”、“吵”，服务器并不以静音为目标 因此“30% = 5700 RPM”是在戴尔设定中的 正常线性关系。 ✅ 原因 4：服务器风扇是以 % 输出功率，而不是线性 RPM 调整 30% 功率 ≠ 30% RPM 比如： 风扇最大 18000 RPM 30% PWM 输出可能产生 ~5000–6000 RPM 这是因为高速风扇的 PWM 控制是非线性的。 📌 总结：这是正常现象 对于 Dell R250： 5700 RPM（30%）属于正常低速 正常工作可能在 8000–14000 RPM 满载可能超过 18000 RPM 如果你听到很吵，也不代表故障——这是 1U 服务器设计的必然结果。

需要修改容器的重启策略为 --restart always。由于容器已经存在，您有两个选择： 方法1：重新创建容器（推荐） 首先停止并删除当前容器： docker stop nginx-proxy-manager docker rm nginx-proxy-manager 然后用正确的重启策略重新创建容器。您需要回想或查找最初创建容器时使用的完整命令，并添加 --restart always 参数。 方法2：使用 docker update 命令 如果您的 Docker 版本较新，可以直接更新运行中的容器： docker update --restart always nginx-proxy-manager 然后重启容器： docker restart nginx-proxy-manager 验证重启策略 检查重启策略是否已生效： docker inspect nginx-proxy-manager | grep -A 5 "RestartPolicy" 您应该看到类似这样的输出： "RestartPolicy": { "Name": "always", "MaximumRetryCount": 0 }, 其他重启选项 除了 always，还有其他重启策略： no - 不自动重启（默认） always - 总是重启 unless-stopped - 除非手动停止，否则总是重启 on-failure - 仅在非正常退出时重启 建议使用方法2，因为它最简单且不会丢失容器配置。

下面是基于 Sub‑Store（GitHub 仓库）README 中整理的支持协议／节点类型 + 支持目标平台／格式的 综合表格。 注意：部分协议可能标为「支持 = 作为输入／输出／部分支持」，项目中并未为所有组合明确标注，因此表中采用“✔／部分／—”表示。 协议／节点类型 说明 支持目标平台／格式 备注 SS (Shadowsocks) 常见代理协议 多平台 ✔ (例如 QX、Loon、Surge、Clash.Meta 等) ([GitHub][1]) 基础支持较好 SSR (ShadowsocksR) SS 的扩展协议 多平台 ✔ (QX、Loon、Stash/Clash 等) ([GitHub][1]) 有支持但可能因客户端限制造限 VMess 核心协议（V2Ray 系） 多平台 ✔ (例如 QX、Loon、Surge、Clash.Meta) ([GitHub][1]) 支持良好 VLESS V2Ray 系的新协议 多平台 ✔ (Surge、Clash.Meta 等) ([GitHub][1]) 支持在不断更新中 Trojan 又一种代理协议 多平台 ✔ (例如 QX、Loon、Clash.Meta) ([GitHub][1]) 支持情况较好 HTTP / SOCKS5 基本代理类型 多平台 ✔ (Surge／Clash.Meta 等) ([GitHub][1]) 注意 “HTTP(s) 不具有标准 URI 格式” 提醒 ([GitHub][1]) WireGuard VPN 型协议 多平台 ✔／部分支持 (Surge、Clash.Meta) ([GitHub][1]) 部分平台支持特定版本 Hysteria / Hysteria 2 较新加速协议 多平台 ✔／部分支持 (例如 Loon、Clash.Meta、Surge) ([GitHub][1]) 新协议，支持可能略有差别 TUIC 新一代协议 多平台 ✔／部分支持 (Clash.Meta、Stash 等) ([GitHub][1]) 较新协议，可能在某些平台表现不同 Snell 较少见协议 多平台 ✔／部分支持 (Surge、Clash.Meta 等) ([GitHub][1]) 使用较少，兼容性可能略逊 SSH (Password auth) 传统 SSH 隧道 支持 ≈ Surge (macOS) 等 ([GitHub][1]) 限于特定平台或场景 AnyTLS / Reality / etc 更前沿传输／混淆协议 部分支持 ✔ (Clash.Meta、Egern 等) ([GitHub][1]) 常见于 “包含官方／商店版不支持的协议” 开关中 支持的目标平台／格式（输出） 下面是 Sub‑Store 明确列出的支持输出平台／格式： Plain JSON ([GitHub][1]) Stash ([GitHub][1]) Clash.Meta (mihomo) ([GitHub][1]) Surfboard ([GitHub][1]) Surge (含 SurgeMac) ([GitHub][1]) Loon ([GitHub][1]) Egern ([GitHub][1]) Shadowrocket ([GitHub][1]) QX (Quantumult X) ([GitHub][1]) sing‑box ([GitHub][1]) V2Ray / V2Ray URI ([GitHub][1]) （已弃用）Clash 原始格式 ([GitHub][1])

✅ 功能： 合并多个源码/配置文件为一个 .txt。 将所有原始文件（保留从 D:\Android\project 开始的相对路径结构）压缩为 .zip。 同时将生成的合并文本文件也一并加入压缩包中（只保留其文件名）。 ✅ 最终完整脚本：含相对路径与合并输出文件打包 import os from datetime import datetime import zipfile # 要合并和压缩的文件路径列表 file_paths = [ r"D:\Android\project\WebPlayerTV\app\src\main\java\com\example\webplayertv\CardPresenter.kt", r"D:\Android\project\WebPlayerTV\app\src\main\java\com\example\webplayertv\Channel.kt", r"D:\Android\project\WebPlayerTV\app\src\main\java\com\example\webplayertv\MainActivity.kt", r"D:\Android\project\WebPlayerTV\app\src\main\java\com\example\webplayertv\MainFragment.kt", r"D:\Android\project\WebPlayerTV\app\src\main\java\com\example\webplayertv\PlaybackActivity.kt", r"D:\Android\project\WebPlayerTV\app\src\main\java\com\example\webplayertv\PlaybackVideoFragment.kt", r"D:\Android\project\WebPlayerTV\app\src\main\AndroidManifest.xml", r"D:\Android\project\WebPlayerTV\app\src\main\res\layout\fragment_player.xml", r"D:\Android\project\WebPlayerTV\app\build.gradle.kts", r"D:\Android\project\WebPlayerTV\settings.gradle.kts" ] # 项目根路径（用于保留相对路径结构） project_root = r"D:\Android\project" # 时间戳 timestamp = datetime.now().strftime("%y-%m-%d-%H-%M-%S") # 合并输出文件路径（.txt） output_path_txt = fr".\webplayertv_merged_output_{timestamp}.txt" # 压缩输出文件路径（.zip） output_path_zip = fr".\webplayertv_merged_output_{timestamp}.zip" # 合并逻辑 with open(output_path_txt, 'w', encoding='utf-8') as outfile: for path in file_paths: outfile.write(f"\n\n==================== {path} ====================\n\n") try: with open(path, 'r', encoding='utf-8') as infile: outfile.write(infile.read()) except Exception as e: outfile.write(f"<< 无法读取文件: {e} >>\n") print(f"文件已合并保存到: {output_path_txt}") # 压缩逻辑（保留从 project_root 开始的相对路径结构 + 添加合并输出文件） with zipfile.ZipFile(output_path_zip, 'w', zipfile.ZIP_DEFLATED) as zipf: for file in file_paths: if os.path.exists(file): arcname = os.path.relpath(file, start=project_root) zipf.write(file, arcname=arcname) else: print(f"跳过不存在的文件: {file}") # 添加合并生成的文本文件（只保留文件名） zipf.write(output_path_txt, arcname=os.path.basename(output_path_txt)) print(f"文件已压缩保存到: {output_path_zip}") 📦 示例 .zip 文件内容结构： WebPlayerTV/app/src/main/java/com/example/webplayertv/CardPresenter.kt WebPlayerTV/app/src/main/java/com/example/webplayertv/... WebPlayerTV/app/src/main/AndroidManifest.xml WebPlayerTV/app/build.gradle.kts WebPlayerTV/settings.gradle.kts webplayertv_merged_output_25-08-08-14-22-00.txt <-- 这个是合并文件（无路径）

不是禁用整个 MainActivity 的触摸，而是只禁用 这个 Activity 里的某个 WebView 控件。 那就不需要用 window.addFlags(WindowManager.LayoutParams.FLAG_NOT_TOUCHABLE) 因为那个会直接把整个 Activity 的触摸事件都屏蔽掉。 WebView 局部禁用触摸的方式 如果你拿到 WebView 实例，可以这样： 方式 1：直接拦截触摸事件 webView.setOnTouchListener { _, _ -> true // 返回 true 表示消费掉事件，不再传给 WebView } 方式 2：继承 WebView 并重写触摸分发 class NonTouchableWebView(context: Context, attrs: AttributeSet?) : WebView(context, attrs) { override fun onTouchEvent(event: MotionEvent?): Boolean { return false // 不处理触摸 } } 然后在布局里用这个自定义 WebView。 方式 3：让 WebView 不可点击 / 不可获得焦点 webView.isClickable = false webView.isFocusable = false webView.isFocusableInTouchMode = false 但这种方式对部分内嵌滚动的 WebView 可能仍会响应滑动，要配合 setOnTouchListener 效果最好。 如果你是在 Flutter 项目里用 WebView 插件（比如 webview_flutter）， 想要在 原生端 禁用，可以通过 平台通道 或直接在插件的 Android 源码里对 WebView 加上 setOnTouchListener 拦截。

✅ 1. Dockerfile with APT and NPM configured to use Aliyun mirrors This is a complete Dockerfile example with: APT sources replaced with Aliyun mirrors NPM registry set to Aliyun’s npmmirror Optional installation of 7z Clean-up of APT cache FROM node:20-bullseye-slim ENV DEBIAN_FRONTEND=noninteractive \ TZ=Asia/Shanghai # Replace APT sources with Aliyun mirrors and install dependencies RUN sed -i 's|http://deb.debian.org|http://mirrors.aliyun.com|g' /etc/apt/sources.list && \ sed -i 's|http://security.debian.org|http://mirrors.aliyun.com|g' /etc/apt/sources.list && \ apt-get update && \ apt-get install -y p7zip curl ca-certificates && \ apt-get clean && rm -rf /var/lib/apt/lists/* # Configure npm to use Aliyun registry RUN npm config set registry https://registry.npmmirror.com WORKDIR /app COPY package*.json ./ RUN npm install COPY . . EXPOSE 12345 CMD ["node", "index.js"] ✅ 2. docker-compose + custom script for mirror configuration You can also use docker-compose to start the container and run a script inside it to configure mirrors at runtime. 🧱 Recommended directory structure: . ├── docker-compose.yml ├── Dockerfile └── scripts/ └── set_aliyun_sources.sh 📄 docker-compose.yml example: version: '3.9' services: mihomo-subserver: build: context: . dockerfile: Dockerfile container_name: mihomo-subserver network_mode: host volumes: -…

配置是： hls_fragment 2; # 每个 TS 片段 2 秒 hls_playlist_length 10; # 播放列表保留最近 10 秒的内容 实际效果 TS 文件数量 计算方式：hls_playlist_length / hls_fragment 这里 10s / 2s = 5，所以 大约会有 5 个 TS 文件（而不是 10 个）。 播放列表行为 每 2 秒生成一个新的 .ts 文件。 .m3u8 播放列表始终包含最近 10 秒的 TS 文件（即 5 个）。 旧的 TS 文件会被自动清理（除非 hls_cleanup off）。 延迟 & 性能影响 延迟：客户端通常会有 hls_fragment * 1.5 左右的延迟（约 3s）。 服务器负载：比 hls_fragment 1 更节省 CPU/IO，比默认 hls_fragment 3 延迟更低。 网络适应性：2s 片段比 1s 更稳定，适合大多数直播场景。 是否需要调整？ ✅ 适合的情况 希望 降低延迟（2s 片段比 3s 更快）。 想 减少 TS 文件数量（5 个左右，而不是默认 20 个）。 适用于 普通直播、视频会议等中等延迟需求。 ⚠️ 潜在问题 如果 hls_playlist_length 10 太小，可能导致： 播放器缓冲不足（网络差时容易卡顿）。 快进/回放时内容太少（HLS DVR 功能受限）。 推荐优化方案 1. 平衡延迟 & 流畅性 hls_fragment 2; # 2s 片段（降低延迟） hls_playlist_length 20; # 保留 20s 内容（10 个 TS 文件） 延迟：~3s TS 文件数：10 个 适合：大多数直播场景 2. 超低延迟模式 hls_fragment 1; # 1s 片段（最低延迟） hls_playlist_length 10; # 保留 10s 内容（10 个 TS 文件） 延迟：~1.5s TS 文件数：10 个 缺点：CPU/IO 负载较高 3. 节省资源模式 hls_fragment 3; # 3s 片段（默认） hls_playlist_length 30; # 保留 30s 内容（10 个 TS 文件） 延迟：~4.5s TS 文件数：10 个 适合：高并发、节省服务器资源 总结 你的当前配置（hls_fragment 2; hls_playlist_length 10）会生成 5 个…