xboard-core

Backend dei nodi di nuova generazione per il pannello cedar2025/Xboard. Riprende da wyx2685/v2node la copertura dei protocolli moderni + il metodo di integrazione del kernel, e da cedar2025/Xboard-Node il livello operativo (push/modalità macchina/certificati/doppio kernel), con la baseline del kernel fissata a Xray-core v26.10.31.

Documenti: docs/ARCHITECTURE.md (architettura e registro delle decisioni) · docs/CONTRACT.md (contratto campo per campo con il pannello, con numeri di riga delle prove) · docs/PANEL-PATCH.md (patch del pannello: perché è stata fatta, come si installa, come si annulla) · docs/STATUS.md (implementato / non implementato / come verificare) · docs/PANEL-IMPROVEMENTS.md (elenco delle modifiche a più lungo termine del pannello)

Perché non continuare a usare i due già esistenti

Dimensione	Xboard-Node (dev 2026-04)	v2node (2026-10)	Questo progetto
Versione del kernel	fork congelato a v26.3.27	v26.9.30	v26.10.31 (con MPTCP disabilitato per impostazione predefinita)
Numero di dispositivi/limitazione di velocità	//go:linkname dirottamento del registro non esportato	copia dell'intero pacchetto dispatcher nel proprio modulo	singola patch app/usergate (3 hunk)
Superficie dei protocolli	vless/vmess/trojan/ss/hysteria2/tuic/anytls (xray+sing-box)	vless/vmess/trojan/ss/hysteria2/tuic/anytls, con crittografia VLESS / mldsa65Seed / xver	lato xray vless/vmess/trojan/ss2022 + REALITY completo e rafforzato; anytls/tuic/hysteria2 delegati a sing-box (zero patch ai protocolli)
Trasporto	ws/grpc/httpupgrade/h2 (rimosso)/xhttp	tcp/ws/grpc/httpupgrade/xhttp	xhttp prioritario, h2/quic rifiutati in fase di compilazione
Push	push tramite handshake WS	solo polling (ETag + msgpack)	push WS + fallback al polling
Certificati	certmagic + 21 provider libdns	lego	certmagic + libdns (soluzione xbn mantenuta)
Modalità macchina	supportata (multi-nodo/singolo processo)	singolo processo multi-Nodes	supportata

Conclusione chiave: la vera divergenza tra i due progetti non è nelle funzionalità, ma in "come inserirsi nel data plane di xray".

• xbn sceglie linkname (patch minime, ma dipende da simboli non esportati);
• v2node sceglie di copiare integralmente il dispatcher (autocontenuto, ma deve seguire le modifiche upstream di 700 righe);
• questo progetto sceglie una terza via: aggiungere un pacchetto app/usergate + 3 hunk nel xray vendorizzato, la semantica del data plane è gestita dal dispatcher di xray stesso, e il gate implementa solo due funzioni pure Admit/Limit.

Indice

cmd/xboard-core/          # 入口（node 模式 / machine 模式 / standalone）
internal/config/          # YAML 配置 + 校验 + 热重载
internal/panel/           # 面板契约：/api/v2/server/*（含 V1 兼容）
internal/kernel/          # 内核抽象（xray / singbox 双实现）
internal/kernel/xray/     # 配置构建（安全默认在此集中收敛）+ 运行时热更新
internal/gate/            # 设备数 + 限速闸门（被 usergate 补丁调用）
internal/sysinfo/         # 面板 status 必填项（cpu/mem/swap/disk，零依赖）
internal/traffic/         # 每用户流量计数与上报
internal/metrics/         # Prometheus 指标 + 健康检查
internal/cert/            # ACME 证书管理（certmagic + libdns）
third_party/xray/         # vendored Xray-core + 补丁序列
panel-patch/              # 面板侧补丁（对 cedar2025/Xboard 的零迁移改动）
docs/                     # 架构决策记录、面板改造清单

Compilazione

Dipendenze: Go 1.27+ (richiesto da go.mod), git, GNU patch.

make vendor          # clone Xray-core v26.10.31 到 third_party/xray
make patches         # 打 patches/*.patch（幂等）
make build           # -> bin/xboard-core
bash scripts/verify.sh   # gofmt + vet + test + build + smoke + vendored 单测 + 补丁幂等

Le macchine senza make (ad esempio git-bash su Windows) eseguono direttamente bash scripts/verify.sh, che è equivalente a make verify; make vendor può essere sostituito da una singola pipe tar, vedi l'implementazione nel Makefile.

Nota per Windows: se %TEMP% non è scrivibile, go segnala creating work dir: ... Access is denied, prima della build è sufficiente export TMP=D:/tmp TEMP=D:/tmp (scripts/verify.sh supporta la variabile GO_TMP).

Lo stato attuale è in docs/STATUS.md: go build ./..., go test ./..., -smoke, i test unitari di app/usergate e app/dispatcher vendored sono tutti superati.

Sicurezza predefinita (vincoli rigidi non sovrascrivibili dal pannello)

1. Tutti i socket in ascolto hanno SetMultipathTCP(false) (CVE-2026-98432), a meno che la configurazione specifichi esplicitamente sockopt.tcpMptcp: true.
2. All'avvio del processo, oltre a debug.SetGCPercent, viene verificato che GODEBUG contenga multipathtcp=0; in caso contrario viene emesso un WARN e si prosegue; install.sh lo scrive per impostazione predefinita.
3. allowInsecure viene rifiutato a livello di build e tradotto in pinnedPeerCertSha256 / verifyPeerCertByName.
4. I trasporti h2/http/h3/quic restituiscono un errore diretto a livello di build (rimossi upstream) e non degradano silenziosamente a tcp.
5. REALITY: validazione di shortIds non vuoto, dest obbligatorio, maxTimeDiff predefinito a 90s, mldsa65Seed/xver/limitFallback* opzionali.
6. minClientVer non viene inviato; se il pannello lo invia, viene registrato un WARN ed esposto in /status, per evitare che i client della famiglia mihomo ricadano silenziosamente.