chen08209：不依赖 VpnService 的 root/iptables 模式超出 FlClash 范围，不打算支持
摘要：针对「为 root 用户提供 iptables 方案，以便不依赖 VpnService 运行」的功能请求，FlClash 作者回复：不依赖 VpnService 的 root/iptables 模式超出 FlClash 的范围，因此不打算支持，关闭该请求。
作者发言 · 第 12 页
作者发言
按原始发布时间排序chen08209：请求抓包与拦截超出 FlClash 范围，不打算支持
摘要：针对「可否添加一个与 Loon 一样的请求抓包拦截功能」的请求，FlClash 作者回复：请求抓包与拦截超出 FlClash 的范围，因此不打算支持，关闭该请求。
chen08209：不支持的代理类型由 mihomo 内核拒绝，FlClash 不改动该解析行为
摘要：针对配置中含 macc 类型导致整个配置解析失败的报告，FlClash 作者回复：该错误来自 mihomo 内核，内核会拒绝它不支持的代理类型；FlClash 不会改动这一解析行为，请向 MetaCubeX/mihomo 上游反馈。该 issue 按 not planned 关闭。
chen08209：FlClash 打包上游 MetaCubeX/mihomo 内核，不打算支持 Smart 等第三方分支
摘要：针对「希望 FlClash 可以选择切换为 vernesong 的 Smart 内核」的功能请求，FlClash 作者回复：FlClash 打包的是上游 MetaCubeX/mihomo 内核，不打算支持切换到 Smart 等第三方分支，按 not planned 关闭该请求。
chen08209：Windows 版被安全软件拦截来自厂商云安全／反诈数据库，并非 FlClash 代码所致
摘要：针对「Windows 0.8.99 被安全软件风控拦截、无法打开」的报告，FlClash 作者回复：该拦截来自厂商的云安全／反诈数据库把安装包标记为风险，并非 FlClash 代码所致，作者也无法把应用从厂商黑名单中移除，相关讨论见 #2655 / #2657。该 issue 按 not planned 关闭。
RPRX：确认 Go 的 X25519 ECDH 并发安全，REALITY 的 hkdf 也改用 crypto/hkdf
摘要：在 XTLS/REALITY PR #40（Config.PrivateKey 改为 *ecdh.PrivateKey、去掉重复推导静态公钥）讨论中，RPRX 回应贡献者关于 Go 1.27 X25519 实现并发安全的说明：看了下代码是并发安全的，顺便把下面那个 hkdf 也改成 crypto/hkdf。原文末尾关于该依赖还有其它文件在用以及 uTLS 的一句为删除线内容，作者已撤回。
Fangliding：一眼 AI 的 WireGuard 批处理 PR 归我管就关了，IPv4 路由本不需要加
摘要：在 XTLS/Xray-core PR #7145（wireguard/udp 批处理与零分配改动）讨论中，Fangliding 回应是否引入 IPv4/IPv6 分离 packet conn：这种一眼 AI 的归我管我就关了，提升并不明显，而且套个 finalmask 也不一定有 oob 读；比如这里 ipv4 路由根本不需要加，所以当初只有 ipv6，这当 bug 修了。
RPRX：Lua 只应限于 Xray 内的计算，不需要特权模式，暂不考虑 curl、iptables
摘要：在 Xray-core PR #7136（Lua 沙盒机制）讨论中，RPRX 表示引入 Lua 本来只是为了自定义计算逻辑，不觉得“控制 Xray”需要特权模式，os.time、os.getenv 既然想到了现在就给就行；并主张让 Lua 仅限于 Xray 内的计算，curl、iptables 之类的就先别想。（该评论末段为删除线内容，作者已撤回，未收录。）
RPRX：Lua 沙盒不能靠 env 限制，需参考其它项目避免逃逸
摘要：在 Xray-core PR #7136（Lua 沙盒机制）讨论中，RPRX 要求沙盒模式多参考其它项目、确保不会出现逃逸问题，并指出不能通过 env 做限制，因为 env 随便改的。（该评论首段为删除线内容，作者已撤回，未收录。）
tokenpls：Clash by Hako 126/127 两版针对内存压力做了一批改动，TestFlight 最新为 iOS 1.0.12 (127)
摘要（节选）：在 ProjectClash/Clash-Client issue #43（iOS 高 QUIC 负载下扩展进程被 jetsam 杀死）下，维护者 tokenpls 回复：126、127 两版针对这类场景做了一批内存改动——测速后的连接及时释放，HY2 分片拼完即放，UDP 会话设了上限，内存紧张时分层回收、不再一刀关掉所有连接。现在 TestFlight 最新是 iOS 1.0.12 (127)，请用同一份订阅再试；如果还会断，导出日志后通过 Telegram 私信 htt…
Leadaxe 提出用 route.default_domain_resolver 对象形式关闭节点域名的乐观 DNS 缓存
摘要（节选）：在自有仓库 LxBox 的 issue #168（仍 open）中，Leadaxe 提出一条待办规范：节点地址会轮换的提供商（A 记录每分钟变化、旧 IP 很快失效）遇到核心的乐观 DNS 缓存时会把客户端留在失效地址上——TTL 过期后核心仍返回旧应答并在后台刷新；DNS 规则也帮不上忙，因为一旦设置了 domain_resolver，节点服务器域名就直接由该解析器解析、绕过规则（sing-box dns/router.go 的 Lookup，`if options.Tra…
alireza0：s-ui 反代 403 源于 header_up 改写 Host，应删除该行由 Caddy 转发原始 Host
摘要（节选）：在 s-ui issue #1290（反向代理配置问题，已关闭）中，alireza0 说明 403 的来源是 Caddy 的 `header_up Host {upstream_hostport}`：它把 Host 头改写成 `127.0.0.1:20000`，因此面板设置里若配了域名，域名校验会拒绝每个请求并返回 403；即便没有配域名，登录也会被拒绝，因为浏览器的 Origin（如 example.com）与 Host 不再匹配。他要求删除这一行，Caddy 默认会转发原…
alireza0：s-ui「Enable UDP by default」未覆盖 AnyTLS，已修复并将在下个版本发布
摘要：在 s-ui issue #1291（「Enable UDP by default」只让第一个代理得到 UDP: true，已关闭）中，alireza0 确认「Enable UDP by default」此前没有覆盖 AnyTLS，所以只有 VLESS 代理得到 `udp: true`。已修复：AnyTLS 代理现在也会得到该设置；另外，未设置 insecure 时 AnyTLS 不再得到 `skip-cert-verify: null`。该修复将包含在下个版本中。
2dust：基于 Linux 系统特性不准备加入启动检测托盘并自动改为关闭到托盘
摘要：在「Linux 启动时检测托盘、有托盘则默认关闭窗口时隐藏至托盘」的功能请求下，v2rayN 维护者 2dust 表示：基于 Linux 系统的特性，不准备添加这样的功能；目前设置中已有该选项，用户可以自己选择。
Fangliding：若 MASQUE 可以工作，则 XHTTP3 或 Hysteria 大概率也可以
摘要：在 Xray-core 关于 Chrome 指纹被 TSPU 拦截的讨论中，Fangliding 表示：如果 MASQUE 可以工作，那么 XHTTP3 或者 Hysteria 大概率也可以。
Fangliding：Lua 沙箱下任意代码执行权限过危险，建议特权功能需启动时加 flag 显式开启
摘要：在 Xray-core PR #7136（为 Lua 增加沙箱机制）的讨论中，Fangliding 提出安全顾虑：理论上一个恶意的 Lua 脚本甚至可以访问 Xray 内置的 DNS，通过 DNS 隧道获得网络后挖矿等，任意代码执行权限还是太危险；他建议改成使用 Lua 的特权功能需要在启动时加一个 lua-(privileged) 的 flag。该 PR 为开放状态、尚未合并。
Fangliding：依赖优先用正式版本号，没有则取两周后的最新 commit
摘要：在 Xray-core PR #7135（把 uTLS 升到 6ebdceb / Chrome 155、注册 hellochrome_155）的讨论中，有人问为什么取 6ebdceb 这个提交而不是最新提交，Fangliding 回应：不用这么急，如果发布了（有 tag）肯定优先用正常的版本号，就算没有也是取两周后的最新 commit。该 PR 为开放状态、尚未合并。
liandu2024：Open-Box「真实路由」探测误报源于响应头过大与内核 DNS 解析，v0.1.318 已修复
摘要（节选）：在 Open-Box issue #583（反馈「Gemini 能打开，但规则页「真实路由」提示访问失败」）中，liandu2024 说明这是规则页「真实路由」探测自己的问题，不影响实际访问，分流本身没问题（规则路由与真实路由的出口一致）。两种测法各有一处：「模拟终端」探测只收 16 KB 以内的响应头，而 gemini.google.com 的响应头约 26 KB（其中一条安全策略头就将近 20 KB），超过即报「response headers too large」，浏览…
DanielLavrushin：b4 的 queue.mark 为重启生效项，不应单独改动 DNS 拷贝监听的 mark
摘要（节选）：在 b4 PR #418（为 Keenetic/Netcraze 修复 iptables UDP 53 队列规则下并发 A+AAAA 丢 AAAA 应答）中，DanielLavrushin 回应一处代码审查意见「应用队列 mark 变更时应更新监听器的 mark」，表示不改：queue.mark 是重启才生效的设置（UI 标注「重启后生效」），在重启前整条包路径沿用连接池启动时的 mark——工作进程的原始套接字在 Worker.Start 中一次性设置 SO_MARK，队列…
yiguodev：OneXray 开发分支实现订阅在「App 托管节点」与「提供方配置」间切换
摘要（节选）：在 OneXray issue #219（功能请求：支持 Remnawave 自定义 JSON）中，yiguodev 回复称已在开发分支为下一次应用更新实现：每个订阅现在可在「App 托管节点」与「提供方配置」之间切换；Remnawave 的 Xray JSON 数组会作为独立完整配置导入。提供方模式直接使用订阅提供的路由与均衡器，不再套用 OneXray 内置的分地区路由与智能节点选择；切回时保留用户原有的 App 路由偏好。OneXray 仍会集成其 TUN 接口并管理日…
Leadaxe：LxBox 隧道选项新增系统 HTTP 代理，默认关闭、将在 2.25.12 之后的下个版本发布
摘要（节选）：在 LxBox issue #165（请求为 Android 10+ 的 VPN 应用加入 http_proxy_support_in_vpn_apps）中，Leadaxe 表示该功能已在模拟器上实现并验证：开启「VPN 设置 → 隧道选项 → 系统 HTTP 代理」后，VPN 网络会通告 127.0.0.1:2081，Chrome 与 Play 通过 CONNECT 把 www.google.com:443 / play.google.com:443 转入内核的 syspr…
RPRX：MASQUE 像 Hysteria 一样绑定了出入站传输层，别被组合出奇怪的东西
摘要：在 Xray-core PR #7121（MASQUE 客户端支持 XMUX、默认使用 Chrome User-Agent）讨论中，RPRX 回应作者 CluvexStudio：MASQUE 像 Hysteria 一样绑定了出入站传输层了吧，别被组合出奇怪的东西。（原文末尾另有一句删除线内容，作者已撤回，不计入。）
Fangliding：直言面向 Cloudflare 的话，用 L4 模式不用 MASQUE 不到一千行就能做完，但不支持 UDP
摘要：在 Xray-core PR #7121 关于 WARP/MASQUE 与 L4 模式的讨论中，Fangliding 表示：愿意直说的话，这就是面向 Cloudflare 编程（毕竟以前连注释都避个嫌）；用 L4 模式、不用那个 MASQUE，不到一千行代码就做完了，他自己以前其实也写过，不过不支持 UDP。
polaris-arch：Polaris 目前仍是半成品、尚未正式对外发布，1.0.0 版本产物后续会重新覆盖
摘要：在 Polaris issue #13（用户反馈 utls 应为可选）中，polaris-arch 回应：它目前只是一个半成品，暂时未对外正式发；1.0.0 的版本产物后面还会重新覆盖；会等主体代码完成之后再统一处理 issue 的部分。
Fangliding：Xray 固定 uTLS 提交是异常情况；Chrome 133 指纹实际覆盖 133~154，并不远古
摘要（节选）：在 Xray-core issue #7131（Bump uTLS: chrome fingerprint is still Chrome 133）中，Fangliding 回应：用 pinned commit 是异常情况，因为他在 uTLS 加了 ECH 的 ALPN 伪装后也没法催他们发版，所以 Xray 这边只好指定 commit 来实装这个功能。对「Chrome 155 是当前稳定版、133 已是少数派」的说法，他表示这说不准：大量其他使用 chromium 的框架（…
Fangliding：功能字段与接口设计不必统一，不同的人设计出的 TUN 接口不同很正常
摘要：在 Xray-core PR #7130 关于是否引入外部 TCP/IP 库的讨论中，Fangliding 回应 RPRX：bool 就 bool 呗，实际上这些功能字段设计不一定就非得长这样；这些字段就是提出之后 patt 那些人跟 AI 说了、AI 再弄的，不同的人设计出不同的接口是完全正常的事，谁优谁劣很难说，也没有人类讨论是否就非得写成这样。各种 TUN 需要的东西八成隔壁（sing-tun）也处理过，说用隔壁的设计接口处理不好也是不太可能的。
LxBox 作者报告编辑器选区边界无法拖拽：会连带拖动标签页与页面
摘要：LxBox 作者在其仓库 issue #167（Проблема. В редакторе. Выделение）报告编辑器中的选区问题：无法拖拽选区边界，拖动时会连带拖动标签页与页面，并附界面截图。
wwqgtxx：sing-tun 汇编 hook 改动需在更广平台验证，Windows 7 仍是支持的最低版本
摘要：在 sing-tun 关于 memmod 汇编 hook 的 PR 讨论中，wwqgtxx 表示：鉴于汇编代码风险高，希望除 Windows 11 x64（26200）之外在更广范围的平台进行测试；由于测试是在虚拟机中进行的，增加其他 VM 版本应该不困难；需要确保代码在 Windows 7 上也能正常运行而不崩溃，因为那是项目仍然支持的最旧版本。
Fangliding：内置 TCP/IP 栈之所以有一千多行是因为它简陋，全抄约等于复制/引入依赖
摘要：在 Xray-core PR #7130（TUN 入站改用内置轻量 TCP/IP 栈替代 gVisor）的讨论中，Fangliding 回应 RPRX 关于 tcp_lightweight.go 只有一千行、没有必要引入外部库的说法：它能有一千多行是因为它简陋，mips 里 commit history 中标出的那一堆 fix 都不是假的，这个（外部库）八成也都有，全抄了约等于复制 / go get 进来。
RPRX：可直接用 buf 接收 TCP/IP 数据再 trim 掉多余头部，减少一次拷贝
摘要：在 Xray-core PR #7130 讨论性能优化时表示：没细看代码，不过显然有一个点是 core 需要先准备一部分内存接收 TCP/IP 的数据，然后 buf 模块又是自己的内存 pool，这里肯定可以减少一次 copy——直接用 buf 来接收 TCP/IP 数据，然后 trim 掉多余的 TCP/IP header。