918ca5d5ba
fix(cluster): 停用状态以「环」为权威，消除长期离线导致的永久分歧
...
承接用户指出的遗留：links 表是每节点本地副本，靠「store→环上行 + 环→store
下行」双向 sync 收敛，但两边都可能被覆盖。其中「本地 store 权威」这条规则有
硬伤，本次改掉。
## 先复现，再动手
写探针验证「入环 token 会不会冲掉本地未传播的决定」，结果比预期严重：
after adopting a stale token: known=true disabled=false
LOCAL DISABLE WAS WIPED by an incoming token
OnToken/AdoptState 是 `e.state = tk.State` **整体替换**。两次 token 之间做出的
停用决定，只要下一轮到达的 token 是「决定之前」捕获的，就会被整个洗掉 ——
决定永远传不出去，转发照旧运行。Group 之所以看起来没这个问题，是因为它每次
adoption 都被 `SetTopologySync` 从 store 重新推上去，而 disabled 没有对应的
「尚未传播」保护。
## 改法：环权威 + 本地决定带「未确认」标记
1. **环权威**：adoption 时把环上的 disabled 写穿本地 store（write-through，
不是监听器），任何 peer 的决定都在一个 token 周期内落地。这终结了旧规则
「各人信自己那份」造成的永久分歧。顺序上只有单向要求：引擎先重新断言本地
未确认决定，再跑 host sync，所以读环绝不会覆盖用户刚做的操作。
2. **未确认决定受保护**（RingEngine.localDisabled）：`UpdateTopologyDisabled`
记下决定，adoption 后由 `reconcileLocalDisabled` 重新断言到刚采纳的 state 上，
于是它会随下一轮 token 传出去。环报回同值时删除该键（全cluster已一致）；
转发从 topology 消失时一并清扫，map 不会无限增长。**false 同样受保护** ——
重新启用也需要传播，丢掉它会把转发永久留在停用态。
3. `TopologyDisabled()` 对未确认决定短路返回本地值，避免状态页与用户刚做的
操作相反。
## 测试（又抓到一个假绿）
新增 4 条：停用/启用跨 adoption 存活、确认后停止断言（让位给 peer 的后续决定）、
追踪表不累积。
★ `TestLocalDisableSurvivesAdoption` **第一版是假绿**：它断言
`TopologyDisabled()`，而该访问器会短路到本地决定，于是「即便即将转发的 state
仍是 enabled」它也报 true。改成断言**下游节点会看到什么**（用一个 peer 引擎
AdoptState 本引擎的 state）后，去掉重新断言如期变红：
the forwarded token carries disabled=false, want true
双向验证通过，这个教训要记：测「声明」而不是测「实际传播的状态」，等于没测。
go build / go vet / go test ./... 全绿，gofmt 干净。
2026-09-26 11:44:28 +08:00
c8ab2584a8
chore(cluster): 去掉 restart 的重复日志行
...
实测 .30 在处理一个 restart 任务时打出两条完全相同的
`restarted t4: portal→aliyun-frps:4434`（同毫秒、同内容），一度像是执行了两次。
核实 worker 进程只有一个（restart 对已运行进程是幂等的），所以不是重复执行 ——
是引擎层（ring_engine.go）与应用层（RestartFn）各打了一条同样的日志。
保留应用层那条：它紧跟实际 worker 操作（谁真正把进程拉起来的），信息位置更准；
引擎层只保留 discard/no-owner 这类异常路径的日志，一次重启对应一行。
go build / go vet / go test ./... 全绿。
2026-09-26 11:06:14 +08:00
8ab52b238a
fix(cluster): restart 任务必须定向投递给 owner，不能被非 owner 吞掉
...
上一提交（5cdc052）只加了执行侧 owner 判定，实测仍然失败：从 .60（非 owner）
启动 owner 在 .30 的 portal，.30 的 worker 一直没起来，且三台日志里既没有
`restarted` 也没有任何错误。
## 真因：任务被非 owner「消费」掉了
pending 命令由 runCommands 的 `for {}` 循环每轮重取 PendingList()，取出后
ClaimPending 即从 map 移除。我当时在「owner != e.ID」时把任务塞回
PendingTasks —— 于是它**立刻又变回待处理**，下一轮循环再次取到，无限
`defer restart`（单测直接跑成死循环，300s 超时）。
而上一版的 `continue` 同样是错的：ClaimPending 已经把任务移除，continue
等于消费，owner 永远收不到。
## 修法：放进「选择」循环，和 Revoke 完全同构
runCommands 里 Revoke 早就有正确的定向投递范式：
owner == e.ID → 我持有，执行
owner == "" 且最低负载 → 转发已消失，兜底消费
否则 → continue（任务**留在 token 里**随环前进）
restart 照抄这套。非 owner 只是不选中它，任务随 token 传给下一个节点，直到
owner 那一跳被取走。owner 已消失也不会永远飘着（`owner == ""` 由最低负载
节点兜底消费），与 Revoke 的处理一致。
执行侧的 owner 判定保留为第二道防线（双保险，两层各有测试覆盖）。
## 测试（又抓到一次假绿 + 一次死循环）
- TestRestartTaskReachesNonLocalOwner：非 owner 处理一 token 后任务必须仍在
token 里，随后 owner 处理时恰好应用 1 次。
★ 第一次写它时反复把**同一个 State 值**喂回 OnToken，导致死循环；改成按
真实环的走法（每跳喂一个新 token）后正常。
- TestRestartOnlyAppliedByOwner：把 peer 设成**最低负载节点**（否则泛用认领
分支根本不会触发，测了等于没测），断言它也不得应用。
★ 第一版 peer 不是最低负载节点 ⇒ 删掉 selection 分支后测试仍然绿，是假绿；
改为最低负载后，删分支 → TestRestartTaskReachesNonLocalOwner 变红。
- 其余：TestRestartTaskBypassesDuplicateClaimGuard、TestRestartFlagSurvives
TokenSerialization 保持绿。
★ 第三次「双向验证」的价值：一个测试抓不到，**另一个**抓到了。单靠一个测试
的绿就下结论是不安全的。
go build / go vet / go test ./... 全绿，gofmt 干净。
2026-09-26 11:03:00 +08:00
5cdc052d01
fix(cluster): restart 任务必须只由 owner 执行
...
上线实测抓到的：从 .60（非 owner）启动 owner 在 .30 的 portal，日志出现
**两条** `.60 restarted t4` —— 关键帧是 `[192.168.2.60:7500] restarted t4`。
pending 任务对所有成员可见，而 restart 分支没有 owner 判定，于是谁先轮到
谁就执行：非 owner 给自己的机器起了一个属于别人的转发 worker，而真正的
owner（.30）什么也没做，worker 一直没起来。
这正是上面 duplicate-claim 防御本来要防的「孤儿 worker + 重复认领」，只是
restart 分支为了绕开那层防御，把 owner 校验也一并跳过了 —— 绕开的是
「重复建条目」的必要性，不是「只有 owner 能动手」的必要性。
修法与 RemoveNode 分支一致：`owner != e.ID` 时只清标志、不执行 handler。
owner 已消失的情况不是错误：条目已被重新标为启用，OfflineReassign() 会在
下一次离线清理时把它转入 pending，再由正常认领流程重新安置。
测试 TestRestartOnlyAppliedByOwner：同一份 restart 任务分别交给 owner 与非
owner，断言非 owner 调用 0 次、owner 恰好 1 次。双向验证 —— 去掉守卫后
如期变红（"a NON-owner applied the restart 1 time(s)"），还原后变绿。
go build / go vet / go test ./... 全绿，gofmt 干净。
2026-09-26 10:48:28 +08:00
1c835425de
feat(cluster): 停用改为「标记」语义，让 disabled 真正随令牌环跨节点传播
...
承接用户提问「设计上停用不是本来就会跨节点传输吗」——核实结论：结构上确实
如此（TopoEntry.Link 是完整 store.Link，整个 State 随 token 每轮广播），但
实际路径断了。断点正是「撤销会删掉 topology 条目」：条目是 flag 的载体，
删了就无处传播，于是停用只能靠一次性 revoke 任务投递给 owner，**owner 当时
不在线就收不到**（实测 .60 记 disabled=1 / .106 记 0，就是这么来的）。
## 改为标记而非移除
撤销不再 RemoveTopology，而是 UpdateTopologyDisabled(true)，条目保留、
Link.Disabled=true、Active=false。Active 正是为此存在：OfflineReassign()
只处理 Active 条目，所以停用的转发在 owner 掉线时不会被重新排队。
- 新增 UpdateTopologyDisabled / TopologyDisabled（照 UpdateTopologyGroup 的桥）
- 新增 store.ReconcileLinkDisabled 作接收端：adoption 时把环上的 flag 落进
本地 store；本节点没有该转发时补一条 disabled 占位行（否则日后在本节点被
claim 会复活），enable 则不建行
- SetTopologySync 由单向（store→环）扩为双向：群组仍上行，disabled 下行
- AddTopology 的 Active 跟随 Link.Disabled（原本硬编码 true，认领一个停用
转发就会复活它）
- 审计日志细分 forward.stop / forward.start，与 forward.remove 区分
## 语义变更带出的两个新问题（都已修）
1. **「启动」这条路断了**。条目保留 ⇒ SubmitTask 被去重挡下，而认领路径的
duplicate-claim 防御又会丢弃「已有 owner」的任务 ⇒ 重启任务发不出去，owner
永远收不到，转发**能停不能起**。
修：新增 Task.Restart 这一独立任务类型 + SubmitRestart + Handler.RestartFn，
显式绕过 duplicate-claim 防御并原地复活（不重复建条目、不重跑 claim 簿记）。
SubmitTask 的守卫同时从 HasTask 收窄为新的 HasActiveTask（跳过 disabled 条目
与撤销任务）；saveCanvas 的判断相应改用 HasActiveTask，避免每次保存都对
已标记的转发重复发撤销。
2. 原本两处 RemoveTopologyEntry 调用（ClaimFn/RevokeFn 的 disabled 分支）在
新语义下会把本该保留的条目删掉，改为 UpdateTopologyDisabled。
## 测试（每个都做了「回退修复行→必须变红→还原变绿」双向验证）
- TestStoppedTopologyEntrySurvivesAdoption —— 离线成员也能学到停用，
一次性 revoke 任务永远做不到这一点
- TestStoppedForwardNotRequeuedOnNodeDeparture / TestAddTopologyRespectsDisabledFlag
—— 标记而非删除为何安全
- TestSubmitTaskNotBlockedByStoppedEntry / TestSubmitTaskStillDedupesActiveForward
- TestRestartTaskBypassesDuplicateClaimGuard / TestRestartFlagSurvivesTokenSerialization
- TestStopThenStartPublishesRestartTask（HTTP 端到端，断言**任务真的发出**）
- TestReconcileLinkDisabled*（store 侧三条）
★ 两次踩到**假绿**：第一版只断言 store 层（newTestHandler 的 Ring 为 nil，
坏掉的路根本没执行）；第二版在 re-enable **之后**才调 SubmitTask，此时新旧
谓词结果相同，测不出差异。都是靠「回退修复行看是否变红」抓出来的 —— 这个
双向验证已经是本项目的固定动作。
go build / go vet / go test ./... 全绿，gofmt 干净。
2026-09-26 10:44:04 +08:00
041cc04dd6
fix(cluster): revoke 在无 topology 条目时静默失效 + 停用状态跨节点不同步
...
上一提交（46e8bc3）上线后实测：`.106` 重启后，被用户停用的
`minecraft` worker **仍然被拉起**。继续挖出两处，均为静默失效型。
## 1. Handler.Revoke 被 RemoveTopology 的返回值挡住了
if claimed.Revoke {
if e.state.RemoveTopology(...) { // ← false 时整个块跳过
if e.Handler != nil { e.Handler.Revoke(...) }
}
}
停 worker 的唯一动作被关在「topology 里确实有条目」的条件里。而
RemoveTopology 对**不在 topology 的转发返回 false** —— 也就是说，越是
需要清理的僵尸转发（条目已丢、worker 还在），revoke 越是完全不做。
这正是 minecraft 的处境：停用请求到达时它已不在 topology ⇒ 返回 false
⇒ Revoke 不执行 ⇒ worker 永远不停 ⇒ 每 33 秒刷一次 connection refused。
修法：停 worker 与摘条目是**两件独立的事**，条目不在也照样停。
（审计日志 forward.remove 仍只在真的摘掉条目时写，这是对的。）
## 2. 停用状态是节点本地的，从不跨节点同步
`links` 表每节点各一份。实测同一时刻 `.60` 记 disabled=1、`.106` 记
disabled=0 —— 因为只有收到停用请求的那个节点写了 store，而**持有 worker
的 owner 往往是另一台机器**，它的副本仍是"启用"。Claim 只读本地 store
⇒ owner 认为该转发是启用的 ⇒ 又被拉起。
修法：task 已携带 Disabled，以它为准，RevokeFn 在本节点把它落库
（已有行改写；没有行则补一条 disabled 记录，防止日后在本节点被 claim
时复活）。
## 测试
- TestRevokeIdempotent 原先只断言"不 panic"，正好漏掉这个 bug —— 它
允许「Handler.Revoke 从不调用」通过。现补上断言：拓扑里没有条目时
**仍必须调用** Handler.Revoke。
- 验证该测试有效：把 `&& removed` gate 加回去 → 如期变红；还原后变绿。
go build / go vet / go test ./... 全绿，gofmt 干净。
2026-09-26 10:05:55 +08:00
46e8bc3703
fix(cluster): 停用的转发会在重启后自己复活 + 令牌轮转日志刷屏
...
从线上三节点（192.168.2.{30,106,60}）的日志里挖出四个问题，本轮修三个。
## 1. 停用的转发会复活（功能性缺陷，实测仍在发生）
线上现象：`minecraft` 在 store 里 disabled=1，worker 却仍在跑，今天
09:46 还在刷 `connect to local service [192.168.2.60:25565]: connection
refused` —— 对着一个用户刻意没启的本地服务死刷。同时三台 logs 里躺着
13956 / 3769 条 `proxy [x] already exists`，每 33 秒一轮。
四处叠加导致：
- stopForward 先读 link，再 SetLinkDisabled(true)，然后把**改之前**的
副本交给 RevokeTask ⇒ published task 带 disabled=false（实测 id/flag
都对不上：topology 里 link.id=223，store 里同一行是 199）
- ClaimFn **无条件** SetLinkDisabled(...,false)。原意是"重新认领时清掉
停用标记"，但启动 reconcile 只要 worker 不在就重新 Claim ⇒ 每次重启
都是"先清标记再起 worker"
- RevokeFn 停了 worker 却**没删 topology 条目**，条目活过 worker
- 于是下次重启 reconcile 看到"owned 但 worker 不在"→ 再次 Claim → 死循环
修法（把 disabled 的所有权交回两个用户动作）：
- Claim **只读** disabled 决定要不要起 worker；为 true 时连 topology
条目一起摘掉，绝不复活
- 启动 reconcile 先按 store 跳过 disabled 的条目（省掉无谓的
claim→skip 往返）
- RevokeFn 除停 worker 外，同时 RemoveTopologyEntry —— 撤销必须是
完整退役，不能只是"停一下"
- stopForward 把 Disabled=true 随 task 发布出去，让持有该转发的节点
即使本地 store 行陈旧也能判断这次停用是用户主动的
## 2. 令牌轮转日志零信息量却占满磁盘
每轮固定 3 行（OnToken cycle=N / forward cycle=N / token-send -> 200），
2 轮/秒，实测本机 **355 行/分钟、7 天 357 万行**，把真事件全淹了。
同一份信息（cycle / lastSync / roundDelayMs / 成员存活）本来就能从
GET /api/manager/cluster/ring 结构化拿到。
加 W4F_DEBUG 开关（沿用项目既有 W4F_ 前缀约定）：稳态三行降级为 debug、
默认关闭；**失败路径一律保留** —— 发送失败、陈旧令牌、非 2xx 正是别人
grep 的对象，静音它们是坏交易。实测同样 12 秒：36 行 → 4 行。
## 3. Link.ID 在 ReplaceLinks 之后必然失效
ReplaceLinks 是 DELETE + 重新 INSERT，sqlite 给每行**新的自增 id**。
任何在改写前捕获的 Link（典型：随 token 环跑的 Link）手里的 id 要么查无
此行，要么命中另一条转发 —— 实测捕获 alpha id=1，改写后新表是 3/4/5，
GetLink(1) 直接落空。
新增 LinkByTriple(local, remote, port) 按自然键查（业务代码本来就一律用
这个三元组标识转发），并把 claim/reconcile 切过去。查无行返回
(Link{}, false, nil) 而非 error：新建的转发没有行，应当照常启动。
## 4. homeagent_device 孤儿（已澄清，非独立缺陷）
它 disabled=1 且从不在 topology 里，是缺陷 1 的另一面（停用标记没进
token），随本次修复覆盖，无需单独处理。
## 测试
新增 4 个测试文件，重点是**验证测试本身抓得住 bug**：
- 临时回退 `ln.Disabled = true` 这行 → TestStopForwardPublishesDisabled-
FlagInRevokeTask 如期变红，还原后变绿
- ⚠️ 第一版回归测试只断言 store 层，是**假绿**：newTestHandler 的 Ring
为 nil，RevokeTask 那条（真正坏掉的）路根本没执行。补了带 ring 的
newRingTestHandler，直接断言**发布出去的 task 上的 flag**
- LinkByTriple 在 ReplaceLinks 前后保持稳定；GetLink(id) 的失效被固化成
一个可见的说明性测试
- 停用/start 往返、per-forward 停用不误伤兄弟转发
- 错误路径不静音、W4F_DEBUG 各种取值
go build / go vet / go test ./... 全绿，gofmt 干净。
2026-09-26 10:02:55 +08:00
0559cc55bd
fix(web): 窄屏底部导航栏错位到顶部 — 顶栏 backdrop-filter 创建了包含块
...
.sb-nav 用 position:fixed;bottom:0 想贴视口底部，但父元素 .sidebar 带
backdrop-filter。backdrop-filter 与 transform/filter 同理，会为后代的
position:fixed 创建【包含块】—— 于是 bottom:0 变成相对顶栏下沿定位而不是
视口，tab bar 贴在顶栏正下方，看起来就是固定在屏幕顶部。
窄屏下关掉顶栏的 backdrop-filter，改用近实色底
color-mix(var(--w4f-card-solid) 92%, transparent)；玻璃模糊保留在
.sb-nav 自身（元素自己的 backdrop-filter 不影响自己的定位）。
顺带 bump 到 0.1.2（version 包 / release.sh / build_installers.sh /
rpm spec + changelog / README 安装示例文件名）。
验证：tsc --noEmit 通过、npm run build 通过；产物 CSS 中确认 720px 段的
.sidebar 已含 backdrop-filter:none；三节点部署后 /status 报告 0.1.2，
环正常（cycle 推进、pending=0、5 条转发 frpc 进程与 topology 归属一致）。
2026-09-03 08:45:22 +08:00
f9f18ae13c
chore: v0.1.1 — 版本号收拢进 internal/version + 发布脚本校验和覆盖安装包
...
- 新增 internal/version 包作为版本号唯一来源，release.sh 通过
-ldflags -X 注入真实 tag。此前 /api/manager/status 与集群 JoinInfo
里各自硬编码 "0.1.0"，产物报告的版本与 tag 无关。
- release.sh：SHA256SUMS 移到原生安装包构建之后统一重算，覆盖
deb/rpm/setup.exe/pkg。此前只算 tar.gz/zip，用户校验安装包会得到
"no file was verified"（v0.1.0 发布时实际踩到）。
- rpm spec / build_installers.sh 默认版本与 changelog、README 安装
示例文件名同步到 0.1.1。
验证：go test ./internal/cluster/... ./internal/httpapi/... 通过；
6 平台产物架构逐个 file 校验正确；linux-amd64 实跑 /status 报告
version=0.1.1（确认 ldflags 注入生效）。
2026-09-03 07:28:13 +08:00
f9c2e9476a
fix: 心跳复活节点、inflight 超时重发
...
1. handleClusterToken：心跳到达时把发送方（前驱）标记为 alive。
之前 forwardToNext 超时把节点 MarkOffline 后就再无途径恢复，
即使下一个心跳证明它活着。心跳是 leader 侧纠正误判的唯一入口。
2. forwardToNext：遍历完所有后继才返回，不要提前 inflight.clear()。
保留 inflight 状态，让 WatchTokenLoss 超时后 StartRing 重发，
重发时 AliveSuccessor 会重新计算，心跳刚复活的节点就能被选中。
这两处补丁一起提交，形成完整的存活复活闭环。
2026-08-28 16:32:51 +08:00
57950a86db
fix: 集群日志重复条目 — 本地 Append 同步推进 Synced 水位
...
根因: Append 只推进 Seq 不推进 Synced。本地追加 seq=N 后 Synced 落后，
下一轮收到对端全量附带(含自己的 seq=N)时 ApplyDelta 视为未见过而再次追加
→ 审计日志出现同 seq 重复行（实测 .30 出现 seq=12/13/14 各两条）。
修复: Append 将 Synced 一并推进到新条目 seq——本地条目天然已同步，
对端回传的同一 seq 被 watermark 幂等跳过。
测试: TestLocalAppendNotDuplicatedByPeerFullLog
实测: 三台各触发 stop+start 制造多条事件 → 三台均 26 条 / 唯一seq 26 /
重复 0 / 水位一致 (seq=26)
2026-08-26 13:30:12 +08:00
1abf1bb447
fix: 集群操作日志同步修复 — 全量回填 + 重启节点 seq 水位抬升
...
两个根因:
1. 离线错过条目永久缺失: token delta 被下游 trim (keep=seq>wm)，
离线节点错过的 seq 再也收不到 → 'log delta gap: want N got N+1' 死循环。
修复: OnToken 改为附带自己的全量日志 (Snapshot)，接收方 ApplyDelta 按 seq 幂等去重，
缺口节点下一轮自动补齐。日志量小(几十条)，开销可忽略。
2. 重启节点重新从 seq=1 编号: NewClusterLog 从 Seq=0 起，重启后产生的新事件
与环上历史 seq 冲突 → ApplyDelta 视为 already-have 静默丢弃 + 全量附带出现歧义 id。
修复: OnToken 收到日志时把本地 Seq 抬到环高水位之上，新编号接在历史之后。
测试: TestFullLogBackfillAfterGap / TestApplyDeltaIdempotentOnFullResend
实测: 三台集群撤销 minecraft 转发 → 三台均记录 seq=10 forward.remove;
恢复后三台均记录 seq=11 forward.add
2026-08-25 11:55:34 +08:00
94b6396738
docs: 更新 README 与 cluster-api — per-forward 模型/网络负载/审计CSV/三级角色/session登录
...
README:
- 特性: per-forward 独立进程、NIC 负载采样、冲突检查、Del 键删除
- 认证: session-cookie 登录 + 三级角色 (superadmin/admin/viewer)
- 审计: 4 个 CSV 导出端点说明
- 构建: dist 不再进 git (编译前需 cp -r)
- 数据目录: 配置/日志路径改为 per-forward 键式
- 架构: 更新模块说明 (worker_key/session/audit)
- API 表: 新增 login/logout + 审计导出 4 端点
- gofmt: store.go 注释对齐
docs/cluster-api.md:
- §9 审计 CSV 导出: 四个端点用法、示例行、公式注入防御说明
2026-08-24 23:52:16 +08:00
f90627f542
Merge remote-tracking branch 'origin/main'
...
# Conflicts:
# internal/httpapi/dist/assets/index-CL42Ur3_.css
# internal/httpapi/dist/assets/index-CbqC9m-j.js
# internal/httpapi/dist/assets/index-RFHYrCiX.css
# internal/httpapi/dist/assets/index-jvouiCgh.css
# internal/httpapi/dist/index.html
# internal/store/store.go
# web/src/api.ts
# web/src/views/ClusterView.vue
2026-08-24 23:30:19 +08:00
2eaa26ba95
feat: worker 日志 CSV 导出 + 集群日志导出菜单完善
...
- handleAuditWorkerLogsCsv: 全环 fan-out 收集每节点 frpc 日志,
逐行展开为 CSV (node/worker_key/remote/worker_state/log_line),
Excel 可直接过滤/pivot 审计
- gatherClusterWorkerLogs: 提取 JSON 与 CSV 共用的日志聚合逻辑
- 路由: GET /audit/worker-logs.csv (read 级)
- ClusterView: 导出 worker 日志改下拉菜单 (JSON/CSV 两格式)
- api.ts: downloadAuditCsv 支持 worker-logs 类型
- gofmt: handlers_audit.go 格式对齐
2026-08-24 23:09:00 +08:00
ef98d9dca1
feat: 审计 CSV 导出 — 用户/API Key/集群操作日志一键下载
...
新增端点 (read 级, 审计 viewer 角色即可导出):
- GET /audit/users.csv: 账号清单 + 最后登录时间
- GET /audit/apikeys.csv: 密钥清单 (前缀+scope+最后使用+过期)
- GET /audit/cluster-log.csv: 令牌环操作日志时间线
(seq/time_utc/node/kind/detail/data_json 六列, detail 为人读摘要,
data_json 保留无损原始载荷)
安全设计:
- RFC4180 转义 (引号/逗号/换行)
- 公式注入防御: =/+/@/tab/- 开头单元格加 ' 前缀
- ISO8601 UTC 时间戳, Excel 直接排序
- 明文密钥不可逆, 仅导出展示前缀
前端:
- UsersView: 账号表/API 密钥表各加「⤓ 导出 CSV」按钮
- ClusterView: 日志导出下拉新增 CSV 选项 (走服务端生成)
- api.ts: downloadAuditCsv() 统一下载管道
测试: csvEscape 全用例 / users+apikeys CSV 内容断言 / 未认证 401
2026-08-24 22:53:52 +08:00
4a41608d94
refactor: 审查修复 — netload 消除重复 /sys 读 + 全项目 gofmt
...
- netload_linux.go: SampleNetLoad 聚合循环不再对每接口重复
readIfaceSpeed (snapshot 已汇总 cur.capMbps), 每次采样省 N 次 /sys 读
- gofmt -w: ring.go/ring_engine.go/auth.go/handlers.go/handlers_logs.go/
handlers_users.go/store.go 结构体字段对齐与注释缩进
- README.md: markdownlint 自动修复 (MD028/MD040)
审查结论: 令牌环本身即互斥协议 — OnToken(收令牌)与 StartRing(发令牌)
在同一节点上由令牌串行化, 不存在需要加锁的竞争; WatchLeader 的读为
良性读, 无需 mutex
2026-08-24 22:24:35 +08:00
0596678c67
feat: 网络接口负载采样 — 令牌环认领决策引入真实 NIC 饱和度
...
- netload_linux.go: 从 /proc/net/dev 字节增量 + /sys/class/net/<iface>/speed
计算网卡利用率 (rx+tx 合计, 多网卡按容量加权, [0,100] 钳制)
- virtio VM speed=-1 时用 1Gbps 软容量兜底, 保持 VM 上采样有意义
- 排除 lo/docker*/br-*/veth*/tun/tap/wg/virbr* 等非物理 uplink,
容器桥接流量不再虚增主机负载
- netload_other.go: 非 Linux 平台编译期 fallback 返回 0
- main.go LoadFn: NetPct 从写死的 10 换成 cluster.SampleNetLoad()
- Score = Forwards*100 + MemPct + NetPct: 主信号仍是转发数,
net 在同转发数节点间打破平局 — NIC 已饱和的节点不再吸引新转发
- 单测: 采样范围断言 + 虚拟接口排除表
实测: 三台集群 net 列显示真实值 (0.02-0.03%), 不再是常量
2026-08-24 16:48:12 +08:00
88b862b515
fix: 首页本地服务只显示 localOnly 转发, 集群转发不再误报为本地服务
...
- handleStatus 的 localStatuses 遍历所有 locals 时跳过非 localOnly,
集群转发只出现在活跃转发卡区 (per-remote 时代的残留逻辑)
- gofmt 格式化 topoKey 定义
- 同步 dist (含 ⚙/⊕ emoji 变体选择器修复)
2026-08-24 16:13:59 +08:00
e3a978888a
feat: per-forward worker 模型 — 每条转发独立 frpc 配置+独立进程
...
核心改动（ring 协议不变，Task 本来就是 {Local,Remote,Link} 三元组）:
- process.WorkerKey: worker 键改为 'local~remote~port' 三元组
- renderForward: 每条 forward 渲染只含 1 个 proxy 的独立 frpc 配置
(替代 renderRemote 把该 remote 全部 forwards 塞进一个进程)
- ClaimFn/RevokeFn: 认领/撤销只操作这一条 forward 自己的进程
- SyncWorkers/auto-start: 只拉起 localOnly 转发的独立进程,
集群转发由 ring 认领节点拉起 (消除三台争抢 proxy already exists)
- RemoteStatus/StartRemote/StopRemote/RestartRemote: remote 级聚合辅助,
保持 /profiles API 形状不变, 前端零改动
- handleStatus/logs: 按 worker key 解析真实 remote 名
效果: 三台节点的 frpc 各自只注册自己拥有的 proxy, 单条转发故障不再波及兄弟
2026-08-24 01:42:58 +08:00
2292ee7f3a
fix: 完善同事未完成的修改 — LAN 地址检测/画布删除撤销/连线删除按钮/Del 键/注释修正
...
- cmd/webui4frpc/main.go: 新增 primaryLANIPv4() 检测内网 LAN 地址,
解决三台内网主机间集群发现失败 (reachableAddr 只回退到 hostname)
- internal/httpapi/handlers.go: applyCanvas 新增拓扑差异检测,
画布删除连线时自动 RevokeTask 避免集群残留
- web/src/api.ts: 新增 addLink / deleteLink API 封装
- web/src/components/PortEdge.vue: × 删除按钮移到端口标签右上角 (绝对定位)
- web/src/views/CanvasView.vue: 启用 Del/Backspace 键删除选中连线
(确认对话框 + 走 onDeleteEdge 逻辑), 修正注释
- embed dist 同步
2026-08-24 01:03:38 +08:00
f29ec81e4a
feat: session-cookie login/logout + three-tier roles (superadmin/admin/viewer) with read-only UI + remove pink theme
...
- cookie-based auth (/login /logout) replacing Basic Auth for UI, enabling logout
- roles: superadmin (account management only), admin (full except accounts), viewer/audit (read-only status+cluster, export logs)
- readonly accounts hide edit buttons (added remote node, group ops, canvas layout/save/import, cluster manage, install) instead of greying them
- auditors see status+cluster only; ordinary admins lose the accounts nav; last-admin guard covers superadmin
- remove pink theme entirely (switcher, [data-theme=pink], leftover localStorage), keep white/blue
2026-08-20 09:08:15 +08:00
2552c14faf
fix: start/stop for ring-only forwards + group sync via ring topology
...
Three issues fixed:
1. Start/stop returned 404 for forwards owned by other nodes:
findLinkByTriple only checked local SQLite store. Added
findLinkFromTopology fallback — startForward/stopForward now look up
ring topology entries when the local store doesn't have the link.
2. Group labels didn't sync through the ring:
handleForwardsAssign only updated local SQLite, never the ring
topology. Added State.UpdateTopologyGroup + Engine.UpdateTopologyGroup
— handleForwardsAssign now updates both. Added topologySync callback
called after every e.state = tk.State (OnToken) and e.state = s
(AdoptState) to re-apply local store group overrides onto the freshly
adopted topology, so they survive state adoption and propagate via
the next token forward. handleForwardsGroupDelete also clears ring
topology entries.
3. Status-merge branch omitted Group field:
ring-only forwards always showed '未分组'. Added Group: t.Link.Group
to the topology-merge forwardStatus.
Verified: 4-node cluster, 5 forwards, group assigned on node-a
propagates to all nodes within one token cycle; stop from non-owning
node succeeds (HTTP 200) and worker stops on the owning node.
2026-08-19 21:52:28 +08:00
465a86c755
fix: status + canvas pages now merge ring topology — all nodes see full cluster picture
...
Root cause: handleStatus built forwards only from local SQLite links table;
handleCanvasGet returned only local store data. Neither merged the ring
topology (which IS synced to every node in-memory). Result: non-claiming
nodes saw only their own claimed forwards, not the full cluster.
Fix: read-time merge in both handlers — iterate ring topology entries and
add any (local, remote, link) not already in the local store. No store
writes (avoids the per-forward stop/start issue that broke the old
topology-derived-canvas model).
Verified: all 4 cluster nodes now show 5 forwards / 4 remotes / 5 links;
isolated node-e correctly shows empty.
2026-08-19 21:24:35 +08:00
eda9bb9597
feat: cluster reliability (leader failover, crash rejoin, key exchange) + auth/users + canvas/forwards enhancements + comprehensive README + API docs
...
- Cluster: forwardToNext offline detection (leader+non-leader), WatchLeader 1s heartbeat fallback, 409 for standalone nodes, Node.NodeKey key exchange via token ring, ClusterPeers persistence + auto-rejoin, Forward delegates to forwardToNext (bugfix)
- Auth: Basic Auth (flag-creds fast path) + bcrypt users (admin/viewer) + Bearer API keys (read/write/admin scope)
- Frontend: UsersView (accounts+API keys), ClusterView (ring/nodeKey/tasks/topology/log), StatusView (group management, per-proxy status), CanvasView (edge toggle/group), PortEdge (disabled/group labels)
- API: handlers split (canvas/forwards/users/logs), canvas export/import, forwards group start/stop/assign/delete, cluster endpoints
- Docs: comprehensive README rewrite (all flags/APIs/auth/cluster), docs/cluster-api.md (cluster management API reference)
- Deploy: run-cluster.sh now 4-node ring + 1 isolated standalone, test-forward.sh updated for 4 nodes
- Removed plan.md (design notes consolidated into README + API docs)
2026-08-19 21:09:24 +08:00
b518a13446
feat: Phase C 完成 — ModelRouter 风格 UI 重设计 + 模拟 frps 测试 + lastSync 修复 + 集群作坊搭建
...
- 主题: sakura×frost 玻璃拟态 (theme.css) + SCSS 变量重映射
- 侧栏: 玻璃侧栏 246px + 渐变品牌区 + 面包屑导航
- 状态页: 玻璃 KPI 卡 + 远程节点/本地服务卡片网格
- 集群页: 英雄玻璃卡 + 横向环拓扑链 + 待办命令/活跃拓扑/日志区
- 令牌环: 新增 lastSync 上次同步时间替代周期计数
- 模拟 frps: frps2/frps3 容器 + test-forward.sh 全链路验证脚本
- 修复: BinaryPath 空导致 worker 不启动, 撤销仅撤第一个 link, 任务复活风暴 (published 追踪)
2026-08-18 23:38:20 +08:00
86b265637d
feat(web): cluster page optimized — self/leader/phase badges, ring arrow, create vs revoke command styling, topology owner highlight, colored log kinds, self highlights
2026-08-18 09:54:29 +08:00
40980944e5
feat(M6): localOnly forward option (loopback→LAN rewrite for cluster, local direct), canvas diff-based create/revoke commands, revoke task semantics, topology derived canvas on sync nodes, LAN addr helper
2026-08-18 09:44:38 +08:00
bf602016b4
feat(web): cluster page shows token ring — ring topology/leader/load, pending tasks, active forward topology with owner, incremental log sync view (e2e verified)
2026-08-18 09:13:20 +08:00
1a8c362080
feat(M6): token-ring protocol complete — task ride+lowest-load claim, topology publish back to token, real worker spawn via claim, incremental log sync e2e
2026-08-18 09:08:22 +08:00
e59feb82c1
feat(M6): token-ring incremental log sync — append-only op log, delta rides token round-2, nodes converge on identical history (e2e verified join events)
2026-08-18 08:59:59 +08:00
f6c4b91a96
feat(M6): token ring data plane + engine — pending adds disappear on claim, topology written back for full cluster view (per authoritative design)
2026-08-18 08:24:37 +08:00
5bd70b90c0
feat: M3 cluster page (LB groups + health check status) e2e-verified failover; M6 cache API + version path hardening + frontend cluster methods
2026-08-17 22:44:04 +08:00
a842198447
feat: docker cluster demo (frps+3 nodes, M6 auto binary pull, tunnel e2e) + fix SelfAddr/W4F_HOST/bootstrap retry, -frpc flag
2026-08-17 21:57:00 +08:00
fd7604cb9c
feat: M6 stage B - cluster heartbeat, new-node bootstrap auto-pull, peer-first install (e2e verified)
2026-08-17 18:05:01 +08:00
79e0b3da79
feat: M6 cluster binary registry + peer exchange (stage A)
2026-08-17 17:53:07 +08:00
467c7124ab
feat: M3 load balancing + health check (model/render/admin API status/UI)
2026-08-17 17:45:03 +08:00
bd3a62a017
fix: worker 进程并发 double-close panic + 状态页连接语义重构 + 集群页骨架
...
- process: spawn 不再重复起 supervise goroutine（Restart 触发旧 supervise close doneCh 后再 close → panic）；新增 closeOnce/supervising 守卫；Start 首次起 supervise，重启循环在同一 goroutine 内
- httpapi: status 增加 connState（connected/connecting/failed/not_started/disabled），由 worker 日志探测真实 frps 连接（不再把本地 worker 状态误当远程 frps 状态）
- StatusView: 远程卡片主状态改为连接状态徽标；启停按钮标注为控制本地 frpc worker；本地转发区保留 worker 状态显示
- 新增 ClusterView 集群页骨架（M3 LB+健康检查载体）+ App.vue 导航接入
- render: bandwidthLimit 从 proxy 顶层移入 transport 段（frpc 0.61 正确 schema，修复真实连不上的 bug）
2026-08-17 15:13:25 +08:00
58906c5a81
feat: M2 HTTP/HTTPS 完善
...
- store: Local 增加 customDomains/subdomain/locations/hostHeaderRewrite/httpHeaders/basicAuth；Remote 增加 vhostHttpPort；migrate() 补列；CRUD 读写（JSOm 编解码）
- render: http/https proxy 输出 customDomains/subdomain/locations/hostHeaderRewrite/httpHeaders/basicAuth
- main: renderRemote 透传 M2 字段（customDomains 逗号拆分 splitCSV）
- web: LocalNode 折叠 HTTP 路由高级区；RemoteNode vhostHTTPPort；StatusView 显示 HTTP 访问端口
- 测试: TestRenderHTTPAdvanced / TestRenderHTTPSUsesCustomDomains；端到端 PUT canvas→config 验证通过
2026-08-17 12:59:12 +08:00
07f25ea067
feat: M1 高级传输参数（P0）
...
- store: Local 增加 useEncryption/useCompression/bandwidthLimit/poolCount/metadatas/annotations；Remote 增加 transportProtocol/transportTls/transportPool/transportTlsServerName；新增 migrate() ALTER TABLE 迁移旧库
- render: 输出 transport 段（protocol/tls/poolCount）与 proxy 高级字段；补 TestRenderTransportAdvanced/OmittedWhenEmpty
- main: renderRemote 闭包透传 M1 字段到 render.Proxy
- web: LocalNode/RemoteNode 折叠高级区表单，types.ts 接口扩展
- 验证：go test 全绿、vue-tsc/build 通过、端到端 PUT canvas→frpc JSON 输出完整
2026-08-17 12:28:54 +08:00
5237e3b594
fix: 注册 PUT /api/manager/settings 使设置保存生效
...
server.go NewServeMux 按方法分发到 handleSettingsPut（原仅注册 GET，PUT 静默返回旧值）
新增 TestSettingsPutRoundTrip 回归测试；gofmt 清理历史格式问题
2026-08-17 12:00:34 +08:00
c1936887a2
webui4frpc: 独立可用的可视化 frpc 控制器 (M0)
...
- 零 frp 源码依赖，单二进制 (Go + Vue3 + VueFlow + Element Plus)
- 画布多对多连线，渲染 tcp/udp/http/https frpc 配置
- worker 进程管理：自愈、日志轮转、崩溃退避重启
- frpc 一键安装 (GitHub Releases) + 手动指定路径
- 三页 UI：状态(默认)/连接配置/设置
- 状态页实时节点/转发状态，节点可增删改启停
- 画布冲突检查：端口/域名冲突标红 + 弹窗拦截保存
- backend 单测覆盖 store/render/process/httpapi/install
- plan.md + FRPC_FEATURES_AUDIT.md 文档
2026-08-17 11:00:26 +08:00
