txlyre

txlyre synced commits to main at txlyre/3x-ui from mirror

  • 16b9b3ce1c chore(deps): bump docs and frontend dependencies Routine minor/patch updates: Next.js 16.2.11 + eslint-config-next, fumadocs, React 19.2.8, Storybook 10.5.3, and assorted tooling. Docs stays on ESLint 9 (^9.39.5): eslint-config-next pulls in eslint-plugin-react 7.37.5, whose newest release still calls the context.getFilename API that ESLint 10 removed, so eslint crashes on every file under ESLint 10. The frontend workspace already ran ESLint 10 without eslint-plugin-react and is unaffected.

6 hours ago

txlyre pushed to master at txlyre/qic

23 hours ago

txlyre synced commits to main at txlyre/3x-ui from mirror

  • 2b1308ca29 feat(notifications): add a consecutive-failure threshold for outbound.down alerts (#5968) Problem: a flaky outbound produces hundreds of false-positive "outbound down" notifications overnight — each fires the moment xray's observatory reports a single failed probe, and the next successful probe fires an "up". applyObservatory forwarded every raw alive:true->false transition straight to EventOutboundDown; xray's observatory has effectively no hysteresis, and nothing on the panel side debounced it (the email/Telegram subscribers are pure formatters). Fix: debounce per outbound. outbound.down now fires only after outboundDownThreshold consecutive FAILED probes (new setting, default 3); outbound.up fires immediately on the first successful probe and only when a down was actually notified. The threshold gates the event itself, so email and Telegram share one knob (exposed next to the outbound.down toggle). The streak counts genuinely new probes (last_try_time advancing), not sampler polls — the sampler runs every 2s but the observatory re-probes per its probeInterval, so counting samples would trip the threshold instantly. outboundDownThreshold=1 reproduces the legacy notify-on-first-failure behaviour. Tuning the observatory's probe interval/timeout is not a workaround: those probes also drive the load balancer's outbound selection, so loosening them to quiet notifications would slow real failover away from a genuinely dead outbound. Notifications don't need observatory-grade latency, so the tolerance belongs at the notification layer, leaving the observatory (and balancer) untouched. Adds TestApplyObservatoryDebounce covering the threshold, probe-vs-sample counting, single-blip suppression and the legacy path. Co-authored-by: Yuriy Khachaturian <[email protected]> Co-authored-by: Claude Opus 4.8 <[email protected]>
  • 9e117bbdd3 fix(clients): keep VLESS xtls-rprx-vision flow when inbound options reload (#5971) The client form cleared the `flow` field whenever `showFlow` was false, but `showFlow` is derived from the inbound options list, which is transiently empty while the options query (re)loads (`inboundOptionsQuery.data ?? []`). During that window `showFlow` is a false negative, so the effect silently dropped a valid `xtls-rprx-vision` flow the user had picked for a Reality/TLS inbound and never restored it — the client was then saved with an empty flow and could not connect with XTLS Vision. Guard the clear so it only runs once the inbound options are actually available. Adds a regression test that reproduces the drop across an options reload. Co-authored-by: Claude Opus 4.8 (1M context) <[email protected]>
  • 8cd71e07ea fix: refresh stale client_traffics row when an inbound-deleted client's email is reused (#6003) * fix: refresh stale client_traffics row when an inbound-deleted client's email is reused AddClientStat's OnConflict was DoNothing on email, so once an inbound is deleted (DelInbound only removes the client_inbounds link, matching ClientService.Detach's intentional Detach-then-later-Attach behavior) the orphaned client_traffics row for that email survives untouched. Re-creating a client under the same email on a new inbound silently kept the old enable/expiry_time/reset/total/inbound_id instead of adopting the new client's config. Switch the conflict path to DoUpdates on inbound_id/total/expiry_time/ enable/reset. up/down stay excluded on purpose: every call for an already-attached identity carries the same config values (one call per inbound), so the refresh is a no-op for that legitimate multi-inbound share, while zeroing usage counters on each additional attach would erase real traffic. Fixes #5958 * fix: don't let AddClientStat clobber import's forced-enabled ClientStats rows github-actions[bot] review on #6003 found that AddInbound writes client_traffics twice for the same import payload: first inserting each ClientStats row (DoNothing, with Enable forced true by controller.importInbound), then calling AddClientStat once per Settings-derived client. With AddClientStat's OnConflict now DoUpdates, that second call was unconditionally overwriting enable (and total/expiry_time/reset/inbound_id) with the Settings.clients[].enable value — which still holds whatever the client had at export time, silently undoing the controller's "always import as enabled" behavior for any client disabled at export. Fix: track which emails were already seeded by the ClientStats loop and skip the AddClientStat call for those emails, leaving the import path's forced values as authoritative. Plain (non-import) creates are unaffected since ClientStats is empty there, so every client still goes through AddClientStat's refresh as before. Also updated a stale comment in addClientTraffic that still described AddClientStat as DoNothing. Added TestAddInbound_ImportForcedEnableSurvivesDisabledSettingsClient, which reproduces the exact regression (verified it fails without this fix) and passes with it.
  • 79e65f63df fix(xray): validate generated egress targets (#5989) * fix(xray): validate panel egress target Avoid generating a loopback panel bridge and routing rule when a saved panel outbound disappears after an outbound subscription refresh. Preserve routing unchanged and log the missing target instead. * fix(xray): guard node and mtproto egress Apply the fail-closed target check to every generated egress bridge. Skip node and MTProto bridge injection when a selected outbound disappears or the relevant JSON cannot be parsed. * test(xray): complete node egress coverage Cover tag and port collisions plus absent and malformed routing. Clarify the fail-closed bridge behavior in the panel and MTProto egress documentation.
  • c87649d9f2 fix(sub) Happ profileEnableRouting button (#6008)
  • View comparison for these 14 commits »

1 day ago

txlyre pushed to master at txlyre/libqirt

2 days ago

txlyre pushed to master at txlyre/qic

3 days ago

txlyre pushed to master at txlyre/qic

3 days ago

txlyre pushed to master at txlyre/qic

3 days ago

txlyre pushed to master at txlyre/libqirt

3 days ago

txlyre pushed to master at txlyre/libqirt

3 days ago

txlyre pushed to master at txlyre/libqirt

3 days ago

txlyre pushed to master at txlyre/libqirt

3 days ago

txlyre pushed to master at txlyre/libqirt

3 days ago

txlyre pushed to master at txlyre/qic

3 days ago

txlyre pushed to master at txlyre/qic

3 days ago

txlyre pushed to master at txlyre/qic

3 days ago

txlyre pushed to master at txlyre/qic

3 days ago

txlyre synced commits to main at txlyre/3x-ui from mirror

  • 16b2bcf9aa fix(database): repair legacy string tgId in inbound settings on upgrade Old panel builds and external tools writing directly to the DB store tgId as a JSON string; parsing such settings into the strict int64 Client model fails with "json: cannot unmarshal string into Go struct field Client.tgId of type int64" and blocks every client operation on that inbound. The one-shot InboundClientTgIdFix seeder already ran on existing installs, so the repair is re-registered as InboundClientTgIdFix2 to run once more on upgrade, and it now preserves numeric string ids instead of zeroing them. The Client model itself stays number-only.

4 days ago

txlyre pushed to master at txlyre/ugushian

5 days ago

txlyre pushed to master at txlyre/ugushian

5 days ago

txlyre pushed to master at txlyre/ugushian

5 days ago