jianf/webui4frpc
1
0
Fork 0
mirror of https://gitcode.com/JianFeeeee/webui4frpc.git synced 2026-10-15 12:14:37 +00:00
Code Issues Packages Projects Releases Wiki Activity
67 Commits 2 Branches 5 Tags
d347d2a648fca737afd614dd0cf60a1134766a9b
Commit Graph

17 Commits

Author SHA1 Message Date
JianFeeeee
d347d2a648 fix(cluster): 把 balancer 真的接进 Handler（端点此前 404） 
上一提交注册了 /cluster/balance 并加了 Handler.Balancer 字段，但构造 Handler 时
忘了赋值 —— 端点因 h.Balancer == nil 走 404 分支。

单测发现不了：它们直接构造 Balancer 调 Report()，从不经过 HTTP 层。
canary 实跑抓到：端点 404（无认证倒是正确 401）。修好后同一 canary 返回 200，
字段齐全、默认 dryRun=true、单节点自认 leader、wouldMigrate 为空。

教训：单元测试覆盖不到"接线"，凡新增端点必须真的起进程打过一次。
 2026-10-06 12:45:28 +08:00
JianFeeeee
8176478269 feat(cluster,httpapi): GET /cluster/balance 只读负载视图 
## 为什么需要它

balancer 的判断原本只能从日志看，而且**只在"确实失衡 且 迟滞窗口已满"时才输出**。
运维问"这个集群均衡吗"——在健康状态下得到的是**沉默**，与"负载均衡没开"
完全无法区分。这个端点把它的判断做成可主动查询的。

## 关键性质：Report() 不扰动迟滞计时器

Report 只读，**不碰 overSince**。否则好奇的运维反复轮询这个端点就会不断重置
"失衡已持续多久"的计时，导致真正的迁移永远不会触发——一个"看一看就把它看没了"
的只读接口。测试 TestReportDoesNotDisturbHysteresis 正是钉住这点：轮询 5 次后
计时器必须原封不动，且随后满足窗口时迁移仍要发生。

## 只 leader 报计划

`wouldMigrate`/`overloadedSince` 仅在 `IsLeader()` 时给出。非 leader 仍返回各节点
Score（那是信息性的），但不报"会迁什么"——否则运维随便查一台节点会拿到与集群
实际行为不符的答案。TestReportOnFollowerHasNoPlan 钉住。

## 返回内容

    nodes[]           各节点 Forwards/MemPct/NetPct/Score
    isLeader          只有 leader 会行动
    overloadedSince   超载已持续多久（迟滞进度）
    wouldMigrate      窗口满足后会迁哪条、从哪到哪
    inFlight          两阶段迁移进行中（revoke 慢 vs 卡死可区分）
    dryRun / enabled  当前是观察还是真迁

## 接线

Balancer 在 NewBalancer 时就创建（HTTP 层需要），W4F_BALANCE_* 解析完再用
SetRatioAndSustain 应用；新增 SetDryRun / DryRun / SetRatioAndSustain，
避免初始化顺序耦合。Handler.Balancer 为 nil 时端点返回 404。

## 测试

新增 4 条：Report 不扰动迟滞（轮询后计时器不变、且迁移仍能触发）、
follower 无计划、窗口满足前后计划的有无、in-flight 可见。
go clean -testcache 后逐包实跑 7/7 全绿。
 2026-10-06 12:44:17 +08:00
JianFeeeee
45a6a76621 feat(cluster): 负载均衡接入运行时 —— 默认 dry-run，显式 opt-in 才真正迁移 
承接 7d5bca5（Balancer 状态机）。本提交接线到 main.go，并让 **dry-run 成为默认**。

## 为什么默认不启用

线上此刻是 `.30` 持 3 条转发、另两台 0 条。按已实现的规则，这会在第一次
检查就立刻触发迁移 —— 而每条迁移都要停一个 frpc worker、断掉活跃连接。
在没有看过真实数据会迁什么之前就把这个开关打开，等于拿生产连接赌一把。

所以：

    W4F_BALANCE_MODE=dry-run   只报告不动手（默认）
    W4F_BALANCE_MODE=on        真正迁移
    W4F_BALANCE_RATIO=2        超载 = Score 超过均值 2 倍
    W4F_BALANCE_SUSTAIN=1800   失衡需持续 30 分钟
    W4F_BALANCE_INTERVAL=10    每 10 秒检查一次

dry-run 走同一套决策与迟滞逻辑（stepDryRun 复用 planBalance），因此它报告的
就是真开会迁的东西 —— 先用它观察，确认符合预期再切 on。

## 只有 leader 平衡

WatchBalance 里 `if !b.engine.IsLeader() { continue }`。搬转发是全集群决策，
令牌是共享的：若每个成员各自决定，必然出现两个节点同时对同一条转发发 revoke。
（这与 Restart/RemoveNode 走同样的 owner 定向是同一类约束。）

## envFloat

新增：环境变量解析失败时回落到默认值并打日志，而不是静默变成 0（0 会被
NewBalancer 当成非法值钳制，但静默钳制无法与"用户显式要 0"区分）。

## 测试

- TestDryRunNeverTouchesTheRing —— dry-run 必须报告"would migrate"且**不发布任何
  任务、不动拓扑、不进入 in-flight**。这是它作为默认值存在的全部意义。
- TestOnlyLeaderBalances —— 非 leader 跑 WatchBalance 不得发布任何任务。

go build / go vet / go test ./...（go clean -testcache 后）全绿，gofmt 干净。

## 下一步（未包含）

集群页 UI 展示超载提示与迁移进度；以及**先以 dry-run 在生产跑一轮观察**，
确认 planBalance 对真实数据的判断符合预期后再决定是否切 on。
 2026-10-06 11:56:23 +08:00
JianFeeeee
fc4cbaa726 fix(cluster): startup reconcile 不该等 leader，否则非 leader 永远不重建自己的 worker 
前两个提交修好分裂与冻结后，滚动重启实测又暴露第三个缺口：

    .106 重入成功 → adopt-state（topology 里 .106 是 gitea_ssh 的 owner）
                  → 但 .106 没有任何 frpc worker，且日志里从无 reconcile

拓扑说 .106 拥有该转发，进程却不存在 —— 拓扑与实际不一致。

## 根因：代码与自己注释矛盾

启动 reconcile 的注释原文就是「every node (leader or not) checks its OWN topology
entries and re-claims any whose per-forward frpc worker is absent」，但代码第一行是

    for { if ring.IsLeader() { break }; sleep 2s }

即必须先当上 leader 才执行。reconcile 做的是**本节点**的活（重建自己拥有的
worker），而三分之一个环里每台都拥有转发 —— 于是所有非 leader 节点永远等不到，
worker 永远不重建。节点可以「已回到集群、拓扑里写着它 own 某转发、却没有任何进程」
这种自相矛盾的状态。

## 修法

新增 Engine.HasSelfInTopology()：当前拓扑是否指名本节点为某条 active 转发
的 owner。reconcile 改等这个条件（30s 上限后无论如何继续，保证孤立节点也能推进），
不再等 leadership。领导者与 reconcile 本就无关：follower 也 own 转发。

## 测试

TestHasSelfInTopology：用**两节点**环，转发由非 leader 的 n2 持有，断言非 leader
仍然报告 true。

★ 这条测试第一版是**假绿**：单节点环里唯一的成员必然是 leader，两种实现结果相同，
加回 IsLeader 门控后测试仍全绿（已实测）。改成两节点、明确断言
`precondition: n2 must not be the leader` 之后，加回门控如期变红：

    a non-leader that owns a forward reports false — the startup reconcile would
    skip it and leave its worker down

go build / go vet / go test ./... 全绿，gofmt 干净。
 2026-10-05 17:54:29 +08:00
JianFeeeee
bfd7265405 fix(cluster): 重入成功后若自己是 leader 必须启动令牌环，否则集群冻结 
上一提交（50c7729）部署后环**仍卡死**，实测 cycle 停在 458198、topology=0、
pending=3。查 .30 日志定位到第二个、也是真正让集群不动的原因：

    ring[.30] rejoined cluster via cached peer 192.168.2.60:7500
    ring[.30] startup reconcile: reclaimed=0 submitted=3
    （此后再无任何 forward cycle / token-send —— 令牌从未转过）

## 根因

retryRejoinCached 在 JoinRing 成功后**直接 return**，把"环会继续转"当作前提。
但 StartRing 只对 leader 生效，而滚动重启恰恰让 leader 自己重入（leader 最后
重启）。此时没有任何节点会转令牌 —— 非 leader 的 StartRing 是 no-op。

结果：leader 重入成功却从不发令牌 → cycle 冻结 → 那三条 pending 转发永远无人
认领 → topology 一直是 0。这与设计文稿 §容错行为不符（环应继续推进）。

## 修法

重入成功后调用 `go ring.StartRing(ctx)`。对非 leader 是 no-op，且内部按
RoundDelay 自节流，多调不会重发，故可无条件调用。

## 测试

TestRejoinThenStartRingCoversTheRejoinPath：用 httptest 起一个假 peer，端到端跑
真正的 retryRejoinCached，断言重入成功后 leader 确实发出了令牌。

★ 这条测试重写过两次才有效：
1. 第一版直接调 `eng.StartRing(...)` —— **假绿**，把修复自己的 helper 当成被测
   对象，回退修复行后仍然全绿（已实测确认）。
2. 第二版改走 retryRejoinCached，但传入 httptest 的完整 URL；JoinRing 自己拼
   "http://<addr>/api/manager/cluster/join"，于是地址变成
   `http://http://127.0.0.1:PORT/...` 而永远打不通。改为裸 host:port。

双向验证：移除修复行后如期变红
（"after a successful rejoin the leader emitted NO token: the ring is frozen"），
还原后变绿。

go build / go vet / go test ./... 全绿，gofmt 干净。
 2026-10-05 17:34:57 +08:00
JianFeeeee
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
JianFeeeee
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
JianFeeeee
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
JianFeeeee
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
JianFeeeee
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
JianFeeeee
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
JianFeeeee
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
JianFeeeee
88b862b515 fix: 首页本地服务只显示 localOnly 转发, 集群转发不再误报为本地服务 
- handleStatus 的 localStatuses 遍历所有 locals 时跳过非 localOnly,
  集群转发只出现在活跃转发卡区 (per-remote 时代的残留逻辑)
- gofmt 格式化 topoKey 定义
- 同步 dist (含 ⚙/⊕ emoji 变体选择器修复)
 2026-08-24 16:13:59 +08:00
JianFeeeee
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
JianFeeeee
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
jianf
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
jianf
cda85ad096 fix: track cmd/webui4frpc/main.go — .gitignore 'webui4frpc' was matching the cmd/ directory, not just the binary 
Also includes the startup auto-submit goroutine: on full-cluster restart,
the leader re-submits local non-disabled, non-localOnly forwards from
SQLite so the ring topology repopulates. SubmitTask is idempotent via
HasTask, so this is safe when tasks survived (single-node restart).
 2026-08-19 22:14:39 +08:00