v3.0.0

Updating

• An update from 2.6 keeps everything as it was. Every setting, every customer and every configuration a customer holds is kept byte for byte, and nobody is disconnected: update from the panel's own button, with w-ui update, or by running the installer again, as before.
• Panels and nodes on 2.6.4 and 3.0 work together, in either direction, so they can be updated in any order. A tunnel of a kind new in 3.0 -- IKEv2, L2TP, PPTP, OpenConnect, a proxy inbound -- is made only on a node that is on 3.0 too; an older node is refused with a message rather than half set up.
• Going back to a release before 3.0 (w-ui → Legacy version) takes down what 3.0 runs beside the panel first: the L2TP agent with any tunnel it carries, and the firewall helper. Their units run the panel's binary with a command an older binary does not know, and an older binary given one starts the whole panel instead -- a second panel on the same tables. For the same reason the installer, given a binary from before 3.0, writes neither.

Added

• The installer installs every protocol. Besides WireGuard, OpenVPN, AmneziaWG and L2TP/IPsec, a new install now brings IKEv2 (strongSwan with its EAP plugins), PPTP (pppd) and OpenConnect (ocserv), each left off until a tunnel uses it, so the first tunnel of each kind starts at once rather than after an install. The automatic install takes all of them without a question; the manual one asks Install every protocol? and, on a no, asks for each, xray and sing-box included. --no-ikev2, --no-pptp, --no-openconnect and --no-proxy-cores leave one out, and the panel still installs it with the first tunnel of its kind.
• The panel can be watched from outside. GET /api/health answers 200 or 503 with no sign-in, for an uptime checker, under the panel's own path; it is not ok when the loop that applies the database to the kernel has stopped or usage is not being written. GET /api/metrics, signed in, gives Prometheus each tunnel up or down, the loop's last run, failed usage writes, the nodes reachable and the backups kept.
• Inbounds are made on a 3x-ui or Pasarguard node from the tunnel form, with everything that panel's own form asks. The form asks for the server first and then offers, in a list as in 2.6, the protocols that server has at its version: this panel's own for a W-UI server; for 3x-ui VLESS, VMess, Trojan, Shadowsocks, HTTP from 2.0, WireGuard and SOCKS/dokodemo-door from 2.5, mixed and tunnel from 2.8, Hysteria2 from 2.9, MTProto from 3.4, TUIC and AmneziaWG from 3.8, MASQUE from 3.10; for Pasarguard (1.0 and later) VLESS, VMess, Trojan, Shadowsocks, Hysteria2, WireGuard, mixed, SOCKS, HTTP, tunnel and dokodemo-door. OpenVPN and the other kinds of this panel are never offered for them.
  • Each protocol's own settings, every transport (TCP with its HTTP header, WebSocket, gRPC, HTTPUpgrade, XHTTP, mKCP), TLS with a certificate file or text, ALPN, fingerprint and ECH, Reality with its target, names, short ids and keys, VLESS fallbacks, sniffing, and an advanced JSON field for anything else.
  • On 3x-ui the inbound's own allowance, expiry and traffic reset, as that panel sets them; on Pasarguard the host its links are written from.
  • Keys are drawn here: Reality x25519 and short ids, WireGuard, Shadowsocks 2022, MTProto secrets.
  • The panel's xray must come back running with the new inbound, or the inbound is taken out again and the reason given; the panel's operator's own users never stop for it.
  • Hysteria2 and MASQUE are served over h3 only, which is what their clients ask for.
  • A Shadowsocks-2022 inbound on Pasarguard gets a standing user, wuikeep_ and a number, whose key nobody is given. A Pasarguard node starts that inbound with the users it has, and with none xray takes no users on it afterwards: the first one added failed, and with it that panel's sync of every user on the node, its operator's own included.
  • Tested on 3x-ui 3.10.2, 3x-ui 2.9.4 and Pasarguard 5.4.1: 34 inbounds of every kind made and checked on each panel, and a customer's traffic through every link a proxy app can dial.
• A 3x-ui or Pasarguard panel's own users can be brought in as customers, when it is added as a node or any time after, from Bring in users on its row: all of them, or the ones ticked. Nothing is made again: each keeps its credentials, its links and the subscription its owner already gave it, which go on working, and this panel's subscription carries the same links beside whatever else the customer is sold -- OpenVPN, WireGuard and the rest from W-UI servers.
  • Its allowance, what it had spent, its expiry (or its days from first use) and its IP limit come with it. From then on they are this panel's: its own limits there are cleared, and it is switched off there when it runs out here and on again when it is renewed.
  • A user switched off there by hand stays off, here too. A customer removed here is left on its panel as it was.
  • On 3x-ui the clients sharing a subscription id are one customer, with a file on each of their inbounds; on Pasarguard a user is one customer, whose links carry every inbound of its groups, and its groups stay its owner's.
  • A client is sent back to 3x-ui exactly as that panel wrote it, with only its switch and limits changed, so fields this panel does not know are kept.
  • Users made later there are brought in by asking again; nothing is taken over unasked. Users made by a W-UI panel are never offered.
  • Tested on 3x-ui 3.10.2, 3x-ui 2.9.4 and Pasarguard 5.4.1 with traffic running through the users' own links the whole time: none of it stopped when they were brought in.
• Two W-UI panels can share a node. Each installation has a tag of its own, and the clients it makes there carry it (wui-<tag>-<n> on 3x-ui, wui_<tag>_<n> on Pasarguard), so neither removes the other's.
• 3x-ui before version 3, and a Pasarguard without API keys, can be nodes too, signed in with an administrator's username and password. The sign-in is kept between rounds, so the panel's operator is not told of a new one every twenty seconds. On 3x-ui 2.x the older API is used, and a client's links come from that panel's own subscription service.
• The outbound at the top of the list carries the customers on a 3x-ui node too. It is put in that panel's xray as wui-out, with one rule that sends this panel's clients into it and nobody else's: the 3x-ui operator's own users leave as before. Direct at the top takes both away. If that xray does not come back running with it, its config is put back as it was.
• A Pasarguard panel can be a node. Choose the type Pasarguard panel and give its address and an API key made there. Its cores' inbounds appear as tunnels under the node's tab; each file on one is a Pasarguard user named wui_ and a number, in a group this panel keeps for that inbound alone, so each file's usage and links stay its own. Pasarguard makes the credentials, its subscription gives the links, and its users' traffic is read into the customer's one total, matching it to the byte. The allowance and expiry are this panel's: a customer who runs out is disabled there. The Pasarguard operator's own users are never touched. Tested against Pasarguard 5.4.1 with its node, with a real client on VLESS, Reality, VMess, Trojan and Shadowsocks.
• A 3x-ui panel can be a node. Choose the type 3x-ui panel when adding a node and give its access URL and an API token made there. Its inbounds -- VLESS with or without Reality, VMess, Trojan, Shadowsocks 2022 and Hysteria2 -- appear as tunnels under the node's tab within twenty seconds, and customers are put on them as on any tunnel. Each file is a client there named wui- and a number; the 3x-ui operator's own clients are never touched. Usage is read from its counters and matches them to the byte; the allowance and expiry are this panel's, and a customer who runs out is switched off there. One user per file is the client's IP limit there. The links are the ones 3x-ui makes, in the customer's one subscription, and follow the inbound when it changes. Tested against 3x-ui 3.10.2 with a real client on every kind.
• Tunnels are grouped by server. Tabs over the list: All, this server, and each node by its name.
• OpenConnect (Cisco AnyConnect), what Cisco Secure Client and openconnect dial. It is a VPN in TLS on any port, 443 by default, with DTLS on UDP.
  • ocserv is run by the panel's agent, and every sign-in is checked by the agent's own RADIUS server. That gives each device its own address, which is how the kernel counts its traffic. One sign-in is one connection: a second device takes the connection over, the first's address is freed for it, and an ended session cannot come back on its cookie.
  • Speed limits follow each session's own device.
  • Camouflage hides the server from anything without its secret where ocserv has it (1.2 and later); on an older ocserv the panel says so instead of claiming it.
  • The panel's own certificate goes on the tunnel when it covers the address; otherwise the tunnel makes one and renews it.
  • Device guides for Cisco Secure Client on Windows, macOS, iPhone, Android and ChromeOS, NetworkManager on Linux, and OpenWrt. The sign-in is withheld on the customer's page as for L2TP.
  • Tested end to end against ocserv 1.1 and 1.3 with real openconnect clients: DTLS, TLS only, camouflage, and one sign-in on two devices.
• PPTP works on Ubuntu 24.04 and later, and on every other system with pppd. The distributions stopped shipping pptpd, so a PPTP tunnel there could not start. The panel now has its own PPTP server: the control connection on TCP 1723 and the GRE of each call. pppd still does everything PPP, so devices, sign-ins, MPPE and addresses are unchanged, and only ppp is installed for it.
  • A pptpd an earlier version started keeps its calls through the update, and is replaced the next time the tunnel restarts.
    ...

dev-latest (b0fa480)

Rolling build of the latest commit on main. Not a stable release; install it with w-ui → 3 (Update to Dev Channel).

v2.6.6

Fixed

• The per-user table counts each device itself, to the byte. A device's
  usage was the customer's total shared out by estimate, read off the
  tunnel's own counters; OpenVPN updates those every ten seconds and the
  panel reads every two, so most of an OpenVPN customer's traffic was never
  shared to anyone -- on a live panel, 98 GB across 18 customers. The kernel
  now counts every device on its own tunnel address, and a customer's usage
  is the sum of their devices, so the rows of the table and the usage above
  it are the same bytes counted once. 2.6.5's Earlier, not split by user
  row is gone: the old estimates cannot be corrected and are not kept. A plan
  whose current period began before this release says from when its table
  counts (Split by user since …) until its next reset.
• A device on a node is charged at the node's usage multiplier, like the
  customer's total, and in a way that keeps the two equal to the byte.
  Before, the total was multiplied and the device rows were not, so on a
  node with a multiplier other than 1 the table could never add up.
• A device on several hosts is counted once in the table. A tunnel with
  spare hosts showed each user once per host, and the table added every one
  of them: with two spare hosts, three times what they had used.
• No usage is lost when the database is busy or briefly fails. Usage
  waited in a queue of 512 updates; while the database was writing the last
  batch the queue could fill and the rest was dropped, and a batch the
  database refused was gone. Usage now accumulates without a limit and a
  refused batch is written by the next one.
• A node reports a customer and their devices from the same moment. The
  two were read in separate steps, so a write landing between them put a
  customer's bytes in one report and their devices' in the next.

v2.6.5

Fixed

• The per-user table on the subscription page adds up to the usage above
  it. OpenVPN rewrites its session counters every ten seconds and the
  panel reads traffic every two, so on most ticks a customer's traffic had
  no file to land on and was left out of the table: an OpenVPN user showed
  about a fifth of what they had really used. Such traffic now goes to the
  customer's files by the shares they last moved in, or to the one file a
  customer has, and the table follows the usage from now on. Traffic used
  before this release and never split by user is shown as one row of its
  own, Earlier, not split by user, so the table's total is the usage.
• Resetting a customer's traffic resets their per-user table too.
  Resetting one customer, several, a group, an interface or everyone, and a
  plan's own renewal, set the usage to zero but left each file's share from
  the period before, so the table showed more than the customer had used.
  Resetting one customer or several also left Downloaded and
  Uploaded at the old period's figures beside a usage of zero.

v2.6.4

Fixed

• Plans that renew now renew. A customer's Renews — daily, weekly or
  monthly — was stored and never acted on: a plan sold as 50 GB a month ran
  out after the first month and stayed out. At the start of each period the
  customer's traffic now goes back to zero, and one cut off for running out
  is back at once. The allowance, the end date and the switch are not
  touched. Periods are counted from the last renewal or reset, or from when
  the plan started, and keep the plan's own day of the month.
• Resetting traffic on an interface brings back who ran out. Its usage
  went to zero, but customers cut off for running out of traffic stayed cut
  off. Resetting all interfaces at once did the same.
• Extending a group leaves plans without an end date alone. It gave a
  customer with no end date — an unlimited plan, or one waiting for its first
  connection — a fixed date, ending the first and starting the second's
  clock early.
• A Listen IP or domain saved without a port keeps the panel's port. It
  moved the panel to port 2096, the subscription service's, after the next
  restart.
• Settings show every label. The external traffic report and the
  subscription service's certificate files showed internal names
  (set.externalTrafficInformEnable) instead of their labels. A test now
  fails on any label a page uses that a language lacks.
• The overview's tiles open the list they count. Depleting, Out of
  data, Expired, Active and Online opened the whole customer list;
  they now open it filtered. A group's name on the Groups page opens its
  members, rather than a search for the group's name.
• A client export imports as it is. Pasting the exported file into
  Import clients was refused for naming no interface; it now goes on the
  first one, as a bare list did.
• Deleting an interface that still has customers says so at once, instead
  of asking for its name to be typed and then refusing.
• One line for running low. The table turned a customer orange from 85 %
  used while the summary and the filter counted them from 80 %; all now use
  80 %.

Changed

• The panel says what each action does. The interfaces page and its
  menus, the hosts and routing forms, the engine's advanced section, the
  Telegram bot and the error messages say interface, never inbound. On
  the Clients page: Add or remove time / Add or remove traffic for
  the selected users, Add servers to the users, Remove servers from the
  users, Set traffic limit and reset cycle and New keys and link; on
  an interface's menu, Take All Clients Off and Detach Clients From….
  The search box says it searches the name and the note, which is what it
  does.
• The customer's own page is one click away: their name in the list opens
  it, with every file, its configuration and its QR code, and files added or
  removed beyond the one per user.
• Interfaces' speed and the reseller limit shown in 2.6.2 are named as
  the rest of the panel names them: the default and the bot's button say
  Users, and resellers sort by Most users.
• Hosts can be checked from their page: Check now tries each address
  the way a customer's device would; Reachable used to say nothing until
  someone called the API.
• Save tells the truth. Outbounds and routing said every change needed a
  restart; changes there apply within seconds. Settings now name the few that
  wait for a restart — where the panel and the subscription service listen,
  their certificates, the trusted proxies and the time zone.
• The documentation is rewritten page by page against the panel: every
  page, column, menu, field, limit and default, in English and in Persian,
  with the Persian pages using the panel's Persian labels.

v2.6.3

Changed

• The installer speaks in colour. Each step is a cyan heading, what
  went well is green, a warning yellow and a failure red. Its questions are
  coloured too: the question in yellow with its default answer in green,
  each set of choices under a magenta heading with the numbers in green,
  notes in yellow, and an answer it cannot take in red. The summary at
  the end colours its labels, its values and the state of each part --
  missing or off in red, not installed in yellow -- with the password and
  the address standing out. The words are the same as before, and a log, a
  pipe or NO_COLOR gets them without any colour.

v2.6.2

Fixed

• A reseller's limit counts users, not customers. A reseller sold 100
  could make a hundred customers for fifty users each -- 5,000 users. The
  limit now adds up the users each customer's plan is for: a hundred
  one-user customers and twenty-five four-user customers are both 100, and
  so is any mix. Raising a customer's users counts against the limit, and
  lowering them frees what they held. A reseller with a limit can no longer
  give a customer any number of users at once (device limit 0), which the
  count could not see. The operators page and the reseller's own account
  box show users against the limit. Customers a reseller already made are
  kept; any made unlimited before this release count as none until they are
  changed.
• Interfaces show their speed. The Speed column on the interfaces page
  always showed "—", and sorting by it did nothing. It now shows what the
  customers on each interface are moving, up and down, the same way the
  customer list does -- for a node's interfaces too, from that node's
  reports -- and sorts by it.
• Interfaces are called interfaces. The interfaces page, its menus, the
  hosts and routing forms, the customer details, the error messages, the
  Telegram bot and the report said "inbound" (in Persian "ورودی" or
  "اینباند") for what the panel calls an interface everywhere else. The
  bot's /inbound command keeps its name.

v2.6.1

Fixed

• A panel can manage its nodes again. Since v2.0.0 a node refused the
  token its managing panel holds for it -- "this part of the panel is the
  owner's" -- on everything the panel does through it: checking the node is
  up, sending it tunnels and customers, collecting its usage, and asking it
  to update. A node on v2.0.0 to v2.6.0 showed as unreachable, customers
  added on the panel never reached it, and its traffic was not counted.
  This applies to every API token, not only the one a managing panel holds
  for its node: as before v2.0.0, a token can again manage interfaces and
  tunnels, routing and outbounds, the engine, hosts, the subscription service
  and nodes, ask a node or this panel to update, and send the Telegram and
  mail test messages. Still refused to any token, as in v2.6.0: changing the
  panel's settings (PUT /api/settings; GET answers a token only the
  display preferences, as it does a reseller, and never the bot token or the
  mail password), backups, tokens, operators, adding, changing or removing a
  node, the subscription page template, restarting the panel, and the
  owner's own account and two-factor.
• An update no longer issues an API token or empties
  install-result.env. Running the installer over an existing install issued
  a new token named installer every time -- one with full access again from
  v2.6.1 -- and rewrote /etc/wui/install-result.env with an empty password
  and that new token, so automation reading the file lost the password. An
  update now leaves the file exactly as the install wrote it (its values, its
  mode, its owner), issues no token, and on an install older than the file
  writes none. A fresh install is unchanged: one token, and the file.
  w-ui update and the panel's own Update never did either.
• A firewall table removed by something else is always reported. When
  another program on the server flushed the whole ruleset just as the
  panel's own rules were changing, the panel put its table back but did not
  log that it had been removed. It now says so every time.

Changed

• A release is published only from a commit CI passed. The release
  workflow now waits for CI on main to finish for the tagged commit -- up
  to 30 minutes -- and builds nothing if it finished red, never ran, or is
  still going by then. It also refuses to publish a release without the
  signing key, where it used to publish one unsigned with a warning: an
  unsigned release is one no panel installs from its update button.
• Every update is now tested from every earlier release. Before a
  release, the panel is started on databases and backups that v1.0.0 to
  v2.6.0 really wrote, and must give back every customer, key, link and
  setting unchanged; an installed earlier release is updated by the
  installer, by the panel's own button and by w-ui update, with a customer
  connected throughout.

Updating

• Update every node by hand, once. A node on v2.0.0 to v2.6.0 refuses the
  panel's request to update itself too, so the panel's Update button
  cannot reach it. On each node server run:

  w-ui update

  From v2.6.1 on, nodes update from the panel again. The managing panel
  itself updates as usual; the order does not matter.

• Extra installer tokens. Each earlier update by the installer left one
  extra installer token on the panel. They are left in place -- they are
  yours -- but nothing uses them: keep the one your automation reads from
  install-result.env, and revoke the rest in Settings → Security → API
  Token, where each shows its prefix and when it was last used.

v2.6.0

Added

• Automatic backup to Telegram, on a time of its own. Settings →
  Telegram → Backup: switch it on and choose every day at a time, every week
  on a day at a time, every few hours, or a crontab line. At that time the
  bot sends the database backup to the admin chat as a file, captioned with
  the panel's version, the server's name, when it was taken and its size.
  Times are in the panel's time zone.

Fixed

• The automatic backup no longer depends on the report. It went only
  with the periodic report, so it came when the report did, and a report
  that could not be built took the backup with it.
• "Every N hours" survives restarts. The schedule counted from when the
  panel started, so a panel restarted (or updated) more often than the
  interval never sent a backup. Where it counts from is now kept in the
  database. A backup that fell due while the panel was down is sent once,
  as soon as it is back; switching it on or changing the time does not send
  one at once.
• A failed backup is said once, not every minute, and an archive too
  large for Telegram (past 50 MB) is no longer left open on the server.
• How many backups to keep applies with scheduled backups off. The
  archives the bot sends are kept on the server too, and were pruned by the
  number the panel started with instead of the one on the settings page.
• A customer named with an underscore no longer stops the report. The
  report is sent as Markdown, and Telegram refused the whole message.
• A backup time more often than every 10 minutes, or one that never comes
  round (the 30th of February), is refused on save.

Panels that had Database Backup switched on keep getting it at the time
their report went.

v2.5.2

Fixed

• Speed shows for every customer moving traffic, whatever the collection
  interval. A customer's speed was averaged over a fixed six seconds, but
  how often traffic is read is a setting (the Engine page): read every ten
  seconds or more, the window was empty most of the time, and only customers
  asked about just after a collection had a speed -- some connected
  customers showed one, some did not. The window is now never less than
  three collections. A node's customers are held to the node's own report
  interval in the same way.
• A speed no longer stays on screen after the customer stops. The list
  refreshes its rows by copying the fields that arrive, and a customer with
  no speed was sent without one, so the last figure stayed; the speed is
  now always sent, null while there is none.

A customer who is connected but moving nothing -- a phone with its screen
off, holding the tunnel open -- counts as online and shows — for speed, as
the classic panel does.