fix(probes): run the same core as the clients and apply settings live

The probe now installs sing-box-lx (with_xhttp), replacing an upstream core left by an earlier install, and verifies the release checksum. Upstream sing-box rejects a whole configuration containing an XHTTP node, which took the probe blind across every node at once.

Also: settings apply without a service restart, check history on the probes tab, atomic binary replacement on reinstall, and the probes menu item appears as soon as the feature is enabled.

Author: ddddeadispose

README.md

@@ -633,16 +633,16 @@ is sent once free space climbs back above the warning level.
 
 A probe is a separate Go binary installed on your own server. It receives a
 hidden subscription, runs a real sing-box core and connects to your nodes the
-same way a customer does, so it answers the question node status cannot: *does
-this node actually work from this network?*
+same way a customer does, which shows whether a node is reachable from that
+particular network.
 
 Enable it under **Settings → Probes**, then add a probe and run the generated
 install command on the host you want to check from. Every result is stored per
-vantage point and never overrides `node.status` — a single probe cannot tell a
-dead node from its own broken uplink.
+vantage point and never overrides `node.status`, since a failure can also come
+from the probe's own uplink.
 
-Failure codes are actionable rather than generic: `net_unreachable` (port
-filtered on the path), `handshake_failed` (dead REALITY destination or DPI),
+Each failure code points at a specific cause: `net_unreachable` (port filtered
+on the path), `handshake_failed` (dead REALITY destination or DPI),
 `auth_rejected` (user not pushed to the running core), `tunnel_no_data` (broken
 outbound or ACL), `degraded`, and `core_down` for a failure of the probe's own
 core.

README.ru.md

@@ -665,13 +665,13 @@ const expected = 'sha256=' + crypto
 
 Пробер — отдельный Go-бинарник, который ставится на ваш собственный сервер. Он
 получает скрытую подписку, поднимает настоящее ядро sing-box и подключается к
-нодам так же, как это делает клиент. Так он отвечает на вопрос, на который
-статус ноды ответить не может: *работает ли эта нода из этой сети?*
+нодам так же, как это делает клиент. Это показывает, доступна ли нода из
+конкретной сети.
 
 Включается в **Настройки → Проберы**, дальше добавляете пробер и запускаете
 сгенерированную команду установки на нужном хосте. Результаты хранятся по точкам
-наблюдения и никогда не подменяют `node.status` — один пробер не отличит мёртвую
-ноду от собственного сломанного аплинка.
+наблюдения и никогда не подменяют `node.status`: сбой может быть и на стороне
+самого пробера.
 
 Коды отказов сразу указывают на причину: `net_unreachable` (порт режется на
 пути), `handshake_failed` (мёртвый destination REALITY или DPI), `auth_rejected`

docs/mcp-user-guide.md

@@ -195,7 +195,7 @@ Allowed statement types: `SELECT`, `WITH`, `EXPLAIN`, `DESCRIBE`, `SHOW`. Mutati
 
 > `probes:read` scope required. Requires probes enabled in panel settings.
 
-Returns what external probes observed by dialling your nodes through a real sing-box core, which is the one thing control-plane data cannot answer: whether a client behind a given ISP can actually connect. See the [probes guide](probes.md).
+Returns what external probes observed while dialling your nodes through a real sing-box core, which shows what a client behind a given ISP sees. See the [probes guide](probes.md).
 
 **Parameters:**
 
@@ -207,7 +207,7 @@ Returns what external probes observed by dialling your nodes through a real sing
 | `hours` | ❌ No | Look-back window, 1–720 (default 1). Over 24 h reads hourly rollups |
 | `limit` | ❌ No | 1–500 (default 100) |
 
-Verdicts: `net_unreachable`, `handshake_failed`, `auth_rejected`, `tunnel_no_data`, `degraded`, `core_down` (the probe's own core failed — this says nothing about the node).
+Verdicts: `net_unreachable`, `handshake_failed`, `auth_rejected`, `tunnel_no_data`, `degraded`, `core_down` (the probe's own core failed, so the fault is on the probe host).
 
 <details>
 <summary>📖 Example: Why users complain about one node</summary>

docs/mcp-user-guide.ru.md

@@ -195,7 +195,7 @@ curl -X POST https://your-panel.com/api/mcp \
 
 > Требуется scope: `probes:read`. Проберы должны быть включены в настройках панели.
 
-Возвращает то, что внешние проберы увидели, подключаясь к вашим нодам через настоящее ядро sing-box, — единственное, на что не отвечают данные панели: может ли клиент за конкретным провайдером реально подключиться. Подробности — в [гайде по проберам](probes.ru.md).
+Возвращает то, что внешние проберы увидели, подключаясь к вашим нодам через настоящее ядро sing-box: как выглядит подключение для клиента за конкретным провайдером. Подробности — в [гайде по проберам](probes.ru.md).
 
 **Параметры:**
 
@@ -207,7 +207,7 @@ curl -X POST https://your-panel.com/api/mcp \
 | `hours` | ❌ Нет | Окно назад, 1–720 (по умолчанию 1). Больше 24 ч читается из часовых роллапов |
 | `limit` | ❌ Нет | 1–500 (по умолчанию 100) |
 
-Вердикты: `net_unreachable`, `handshake_failed`, `auth_rejected`, `tunnel_no_data`, `degraded`, `core_down` (отказало собственное ядро пробера — о ноде это не говорит ничего).
+Вердикты: `net_unreachable`, `handshake_failed`, `auth_rejected`, `tunnel_no_data`, `degraded`, `core_down` (отказало собственное ядро пробера, проблема на его хосте).
 
 <details>
 <summary>📖 Пример: почему жалуются на конкретную ноду</summary>

docs/probes.md

@@ -2,25 +2,21 @@
 
 > Read this in [Russian](probes.ru.md).
 
-A probe is a small Go binary you install on **your own** server. It gets a hidden subscription from the panel, starts a real sing-box core, and connects to your nodes exactly like a customer would — then reports what actually happened.
+A probe is a small Go binary you install on **your own** server. It gets a hidden subscription from the panel, starts the same core the Click Connect clients run, connects to your nodes exactly like a customer would and reports the result.
 
 ---
 
 ## 📖 Why This Exists
 
-The panel already knows whether a node agent is alive, whether the process is running and how much traffic was accounted. None of that answers the question customers actually ask:
-
-> "Why can't I connect from my ISP?"
-
-A node can be perfectly healthy from the panel's point of view while:
+The panel sees its own control plane: whether a node agent is alive, whether the process is running and how much traffic was accounted. A node can look healthy there while:
 
 - the port is filtered by a specific carrier,
 - the REALITY masquerade destination is dead, so the TLS handshake never completes,
 - the user was never pushed to the running Xray instance, so credentials are refused,
 - the tunnel is established but no data flows because of a broken outbound or an ACL rule,
 - the exit IP landed on a blacklist, so a specific resource is blocked.
 
-A probe reproduces the client path end to end and names which of these it is.
+A probe walks the client path end to end and names which of these happened.
 
 ---
 
@@ -48,7 +44,7 @@ A probe reproduces the client path end to end and names which of these it is.
 1. **Enrollment.** The panel issues a single-use token valid for 24 hours. The probe exchanges it once for a permanent token; only SHA-256 hashes are stored for verification.
 2. **Profile.** The probe asks what to check: nodes, inbounds, the resource checklist, cadence and the speed-test budget.
 3. **Subscription.** Every probe owns a hidden user with its own subscription. That user is excluded from all listings and statistics, so probe traffic never shows up as customer traffic.
-4. **Checks.** One local SOCKS listener is opened per checked inbound, which is what pins a measurement to exactly one node inbound rather than to whatever the balancer picked.
+4. **Checks.** One local SOCKS listener is opened per checked inbound, so every measurement is pinned to exactly one node inbound.
 5. **Reporting.** Results are aggregated locally into windows and shipped gzipped. Undelivered batches are spooled on disk, so a panel outage costs no measurements.
 
 The panel never connects to a probe: everything is initiated by the probe, so it works behind NAT and on residential links.
@@ -65,7 +61,7 @@ Then **Probes → Add probe**, give it a name that describes the vantage point (
 
 ```bash
 curl -fsSL https://github.com/ClickDevTech/CELERITY-panel/releases/latest/download/celerity-probe-install.sh \
-  | PANEL_URL='https://panel.example.com' ENROLL_TOKEN='<token>' sh
+  | sudo PANEL_URL='https://panel.example.com' ENROLL_TOKEN='<token>' sh
 ```
 
 **Windows (elevated PowerShell):**
@@ -75,7 +71,9 @@ $env:PANEL_URL='https://panel.example.com'; $env:ENROLL_TOKEN='<token>'
 irm https://github.com/ClickDevTech/CELERITY-panel/releases/latest/download/celerity-probe-install.ps1 | iex
 ```
 
-The installer downloads the probe and a sing-box core, enrolls once, and registers a service (systemd, launchd or a Windows service). The enrollment token is passed through the environment, never on the command line, because the process table is readable by other local users.
+The installer downloads the probe and a core, enrolls once, and registers a service (systemd, launchd or a Windows service). The enrollment token is passed through the environment, never on the command line, because the process table is readable by other local users.
+
+The core is [sing-box-lx](https://github.com/Leadaxe/sing-box-lx) — the same build the Click Connect apps use. It is upstream sing-box plus the transports the panel can publish; upstream refuses an entire configuration that contains an XHTTP node, so a probe on upstream would go blind on every node at once. An install that finds an upstream core in place replaces it, and the probe writes a warning to its log if the core it starts lacks `with_xhttp` while the fleet has XHTTP nodes. Set `CORE_REPO` before running the installer to pull the core from somewhere else.
 
 
 | Platform | Service                                                             | Data directory                  |
@@ -103,15 +101,15 @@ The installer downloads the probe and a sing-box core, enrolls once, and registe
 | Resource checklist        | empty   | One `id` + `url` pair per row, checked through every node           |
 
 
-Speed measurement burns real traffic on your own nodes, which is why it is bounded three ways and spends its daily budget round-robin across nodes instead of letting one node consume everything.
+Speed measurement burns real traffic on your own nodes, so it is bounded three ways, and its daily budget is spent round-robin across nodes.
 
-**Scale note.** The number of stored series is *probes × nodes × resources*. The panel warns when that product grows past a few thousand — at that point lengthen the intervals rather than adding probes.
+**Scale note.** The number of stored series is *probes × nodes × resources*. The panel warns when that product grows past a few thousand; at that point lengthen the intervals.
 
 ---
 
 ## 🔍 Reading the Results
 
-Results are always presented **per vantage point**, and probe verdicts deliberately never change `node.status`. With a single probe there is no way to tell "the node is down" from "the probe's own uplink is broken" — that distinction needs a quorum of probes on different networks.
+Results are always presented **per vantage point**, and probe verdicts never change `node.status`. A failed check can also come from the probe's own uplink; telling the two apart needs a quorum of probes on different networks.
 
 Failure codes map directly to an action:
 
@@ -123,21 +121,21 @@ Failure codes map directly to an action:
 | `auth_rejected`    | Tunnel stands, credentials refused       | User not pushed to the running core — a sync problem        |
 | `tunnel_no_data`   | Authenticated, but nothing flows         | Broken outbound or an ACL rule                              |
 | `degraded`         | Works, but slowly                        | Overload, or a bad route to this vantage point              |
-| `core_down`        | The probe's own sing-box was not running | Fix the probe host; this says nothing about the node        |
+| `core_down`        | The probe's own sing-box was not running | The fault is on the probe host                              |
 
 
-Resource results are separate on purpose: a blocked resource means a geo-block or a blacklisted exit address, **not** an outage. Only 403 and 451 are treated as a block; a 500 or a transport error is recorded as a failed check without blaming a geo-restriction.
+Resource results are kept separate: a blocked resource points to a geo-block or a blacklisted exit address. Only 403 and 451 count as a block; a 500 or a transport error is recorded as a failed check.
 
 Two warnings worth acting on:
 
-- **Same host.** If a probe's egress IP matches one of your nodes, its checks of that node prove nothing — it never leaves the machine. The UI flags this.
+- **Same host.** If a probe's egress IP matches one of your nodes, its traffic to that node never leaves the machine. The UI flags this.
 - **Virtual nodes.** A virtual node is a `urltest` group. Both the group and its leaves are checked, and the group result records which leaf the balancer actually picked.
 
 ---
 
 ## 🪝 Alerts
 
-Webhooks fire on state transitions, not once per window, so an alert arrives without waiting for the rollup:
+Webhooks fire on state transitions, so an alert arrives without waiting for the rollup:
 
 
 | Event                      | Fired when                                                       |
@@ -153,17 +151,17 @@ A local core failure (`core_down`) never raises a node alert.
 
 ## 🤖 AI Assistant
 
-The `query_probes` MCP tool exposes the same data to an AI client. It requires the `probes:read` scope — probe data reveals vantage points and egress addresses, so it does not ride on general statistics access. See the [MCP guide](mcp-user-guide.md).
+The `query_probes` MCP tool exposes the same data to an AI client. It requires its own `probes:read` scope, because probe data reveals vantage points and egress addresses. See the [MCP guide](mcp-user-guide.md).
 
 ---
 
 ## 🔐 Security Model
 
 - A probe holds **client credentials only**. It has no rights on any node, no SSH access and no panel session.
 - Tokens are verified against SHA-256 hashes and compared in constant time. The permanent token is additionally stored encrypted so the panel can re-display an install command.
-- Deleting a probe removes its hidden user, its subscription and its results immediately, and pushes the removal to the running Xray instances. Since the credentials are plain client credentials, revocation speed is what bounds their lifetime — there is no IP or ASN pinning.
-- The traffic cap on the hidden user is the second bound: a leaked probe subscription cannot be used for free traffic beyond it.
-- Ingest is idempotent. A redelivered batch is acknowledged without being stored twice, which is what makes at-least-once shipping safe.
+- Deleting a probe removes its hidden user, its subscription and its results immediately, and pushes the removal to the running Xray instances. There is no IP or ASN pinning, so revocation speed is what bounds the lifetime of leaked credentials.
+- The traffic cap on the hidden user is the second bound: a leaked probe subscription is limited to that amount of traffic.
+- Ingest is idempotent. A redelivered batch is acknowledged without being stored twice, which makes at-least-once shipping safe.
 
 ---
 
@@ -175,11 +173,11 @@ The `query_probes` MCP tool exposes the same data to an AI client. It requires t
 | Probe stays "awaiting installation"                 | The enrollment token expired (24 h) or was already used — reissue it from the panel       |
 | Every node reports `core_down`                      | sing-box is missing or not executable on the probe host; check the service log            |
 | Every node reports `auth_rejected`                  | The probe user did not reach the nodes — run a sync and check the node status             |
-| One node reports `net_unreachable`, others are fine | Port filtered on the path from this vantage point — that is exactly what the probe is for |
+| One node reports `net_unreachable`, others are fine | Port filtered on the path from this vantage point                                         |
 | No data after install                               | The feature is disabled in settings, or the probe cannot reach `PANEL_URL` over HTTPS     |
 
 
-Logs: `journalctl -u celerity-probe -f` (Linux), `tail -f /usr/local/var/celerity-probe/probe.log` (macOS), the service log in the data directory (Windows).
+Logs: `sudo journalctl -u celerity-probe -f` (Linux — without root the journal shows nothing), `tail -f /usr/local/var/celerity-probe/probe.log` (macOS), the service log in the data directory (Windows).
 
 ---