AnyTLS server setup creates a password-authenticated TLS service and a client that verifies the certificate before carrying application traffic. This guide uses sing-box 1.14.3 on two authorized Ubuntu 24.04 LTS amd64 hosts, with a loopback client proxy and a separate server unit. It follows official documentation; no complete end-to-end author test was performed.［1］

Key Takeaways

Certificate verification and the user's password solve different problems.

Keep the default padding and idle-session behavior while establishing a baseline.

Test new connections after changing credentials; a configuration edit is not revocation evidence.

Restore only this exercise's service, firewall, certificate copies, and client settings.

When is an AnyTLS server setup appropriate?

Use AnyTLS when you can administer the complete lifecycle of your own endpoint: certificate issuance, private-key access, users, logs, updates, and retirement. Start with the guide to assigning self-hosting responsibilities. If you mainly want an everyday public exit, compare the maintenance obligations of VPS and managed VPN options before committing to this service.

The Trojan protocol overview is background for a related TLS-based approach, not permission to import a Trojan profile. The guide to VPN connection scope helps distinguish one application proxy from whole-device routing. This article covers the chosen core at both ends, not a GUI, panel, REALITY combination, or compatibility matrix.

Reserve TCP 24444 on a dedicated server and loopback 1080 on a separate client. Obtain a valid certificate chain and matching key for your own domain through the CA's existing supported renewal procedure. The server's assigned local address can differ from its externally mapped address. Only use a NAT mapping you are authorized to administer.

Before installation, privately record package versions, service enablement, APT source files, relevant firewall rules, addresses, and resolver settings. Test a new management connection through an independent SSH or provider-console path. All names below must be unused; if they belong to a working installation, stop and adapt the procedure with its owner rather than overwrite it.

Step 1: Install the stable core and separate credentials

Install Ubuntu's curl, ca-certificates, and openssl prerequisites, then add the official stable APT source on both hosts. Select the exact APT version whose core is 1.14.3 from the displayed list. The placeholder is intentionally not an installable version. Stop if the required release is unavailable; do not silently install a beta.［5］

sudo apt-get update
sudo apt-get install curl ca-certificates openssl
sudo install -d -m 755 /etc/apt/keyrings
sudo curl -fsSL https://sing-box.app/gpg.key -o /etc/apt/keyrings/sagernet.asc
sudo chmod 644 /etc/apt/keyrings/sagernet.asc
sudo tee /etc/apt/sources.list.d/sagernet.sources >/dev/null <<'REPO'
Types: deb
URIs: https://deb.sagernet.org/
Suites: *
Components: *
Enabled: yes
Signed-By: /etc/apt/keyrings/sagernet.asc
REPO
sudo apt-get update
apt-cache madison sing-box
sudo apt-get install sing-box='APT_VERSION_FOR_1.14.3' curl ca-certificates openssl
sing-box version

Verify both executables report 1.14.3. Preserve a recoverable package or release artifact and check the project's release and security information before upgrades. Inspect any package-provided default service; this exercise does not start or repurpose another working unit.

On the server, create the isolated account and copy the already-issued chain and private key. Replace /PRIVATE/SOURCE/ with their actual protected location. No private key belongs on the client.［4］

sudo useradd --system --user-group --no-create-home --shell /usr/sbin/nologin sbanytls
sudo install -d -o root -g sbanytls -m 750 /etc/sing-box-anytls
sudo install -o root -g sbanytls -m 640 /PRIVATE/SOURCE/fullchain.pem /etc/sing-box-anytls/fullchain.pem
sudo install -o root -g sbanytls -m 640 /PRIVATE/SOURCE/privkey.pem /etc/sing-box-anytls/privkey.pem

Generate a separate password in a private terminal with openssl rand -base64 32, store it securely, and transfer it through an authorized secure channel. Paste it into a private editor, not a shell argument. Do not share profiles, screenshots, or logs containing reusable credentials. A users.name label is for identifying the configured user, while the password is the authentication secret.［2］

Step 2: Configure sing-box AnyTLS and its service

Create /etc/sing-box-anytls/config.json using a privileged private editor. Substitute an IPv4 address actually assigned to this host for SERVER_LOCAL_IPV4, and substitute the password at both ends. Set the file to owner root:sbanytls, mode 640.

{
  "log": {
    "level": "info"
  },
  "dns": {
    "servers": [
      {
        "type": "local",
        "tag": "system-dns"
      }
    ]
  },
  "inbounds": [
    {
      "type": "anytls",
      "tag": "anytls-in",
      "listen": "SERVER_LOCAL_IPV4",
      "listen_port": 24444,
      "users": [
        {
          "name": "reader-test",
          "password": "REPLACE_WITH_PRIVATE_PASSWORD"
        }
      ],
      "tls": {
        "enabled": true,
        "certificate_path": "/etc/sing-box-anytls/fullchain.pem",
        "key_path": "/etc/sing-box-anytls/privkey.pem"
      }
    }
  ],
  "outbounds": [
    {
      "type": "direct",
      "tag": "direct"
    }
  ],
  "route": {
    "final": "direct",
    "default_domain_resolver": "system-dns"
  }
}

Keep padding_scheme omitted so the implementation uses its default. Custom padding is outside this task and does not establish invisibility or reliability on a particular network. The server's typed local DNS resolver and default_domain_resolver make destination-name resolution explicit; they do not change the client's system resolver.［2］［6］

Save this separate unit as /etc/systemd/system/sing-box-anytls.service, root-owned mode 644. It runs without a privileged port or access to a user's home directory.

[Unit]
Description=Isolated sing-box anytls reader exercise
After=network-online.target
Wants=network-online.target

[Service]
User=sbanytls
Group=sbanytls
ExecStart=/usr/bin/sing-box run -c /etc/sing-box-anytls/config.json
NoNewPrivileges=true
ProtectSystem=strict
ProtectHome=true
PrivateTmp=true
Restart=on-failure
RestartSec=3

[Install]
WantedBy=multi-user.target

sudo -u sbanytls /usr/bin/sing-box check -c /etc/sing-box-anytls/config.json
sudo systemctl daemon-reload
sudo systemctl start sing-box-anytls.service
sudo systemctl status sing-box-anytls.service --no-pager
sudo ss -lntp

A successful configuration check or active unit does not prove TLS, password acceptance, or forwarding. Review only bounded recent logs with sudo journalctl -u sing-box-anytls.service -n 30 --no-pager; redact addresses and secrets before sharing diagnostics. Fix private-file ownership if access fails rather than broadening key permissions.

Step 3: Limit TCP access and connect a loopback client

Use the existing firewall manager. If UFW is already active and owns policy, allow only TCP from the test client's observed public address to this server's local address and port 24444, with comment anytls-test; apply the matching narrow provider allowance where necessary. Save the exact rule for removal. Keep management access and never reset a shared firewall to make the connection work.

For an already-active UFW policy only, replace both address placeholders before adding this rule:

sudo ufw allow proto tcp from CLIENT_PUBLIC_IP to SERVER_LOCAL_IPV4 port 24444 comment 'anytls-test'

Create anytls-client.json privately. Replace SERVER_PUBLIC_IPV4 with the reachable numeric endpoint, and replace anytls.example.com with the real certificate name. The client verifies that name against the certificate while connecting to the chosen IP. insecure: false stays unchanged.［4］

{
  "log": {
    "level": "info"
  },
  "inbounds": [
    {
      "type": "mixed",
      "tag": "local-in",
      "listen": "127.0.0.1",
      "listen_port": 1080
    }
  ],
  "outbounds": [
    {
      "type": "anytls",
      "tag": "anytls-out",
      "server": "SERVER_PUBLIC_IPV4",
      "server_port": 24444,
      "password": "REPLACE_WITH_PRIVATE_PASSWORD",
      "tls": {
        "enabled": true,
        "server_name": "anytls.example.com",
        "insecure": false
      }
    }
  ],
  "route": {
    "final": "anytls-out"
  }
}

The example leaves idle-session options omitted. The outbound documentation gives defaults of 30 seconds for both checking interval and idle timeout, with zero minimum idle sessions; an illustrative value of five in the documentation's structure is not the default. An idle-session timeout is evaluated during periodic checks, not an exact application-disconnection deadline.［3］

chmod 600 anytls-client.json
sing-box check -c anytls-client.json
sing-box run -c anytls-client.json

Run the client in the foreground and leave it running. The mixed listener accepts explicitly configured HTTP or SOCKS clients only on loopback; it is not a device-wide capture mechanism. Keep existing network controls and unrelated proxy applications unchanged.

Step 4: Check the AnyTLS TLS certificate and failures

From a second terminal, send one bounded request through SOCKS with remote hostname resolution:

curl --noproxy "" --proxy socks5h://127.0.0.1:1080 --connect-timeout 5 --max-time 20 https://example.com/

A completed request establishes only that application's tested path. For browser exit verification, use a separate profile explicitly configured for the loopback HTTP proxy and inspect the address visible to that browser request. Restore its previous proxy setting afterward. Neither result proves coverage for other apps, DNS, IPv6, or UDP.

Prepare private configuration copies for negative tests. Ctrl-C only your foreground client, restart it with the selected file, and issue a fresh request. This prevents a pooled authenticated connection from concealing an incorrect password or changed name.

Reader check	Expected observation	Interpretation or recovery
Correct password and certificate name	A fresh request completes	Record the request and time privately, without claiming throughput
Change only password	A fresh connection cannot authenticate	Confirm the effective client file and absence of an old listener
Change only certificate name to an unrelated name	TLS verification fails	Inspect the certificate chain and names; keep verification enabled
Stop only this server unit	A new request fails	An apparent success needs investigation of the actual serving process
Leave client idle, then make a new request	The client can create a session again if the service remains healthy	Idle-pool cleanup alone is not an outage
Remove user, check file, restart this server unit	Removed credentials fail on a fresh connection	The restart also interrupts this unit's existing connections
Restart with an authorized retained or new user	A fresh request works again	Restore the last safe file if it fails; do not revive compromised credentials

The table defines reader checks, not measured results. For idle behavior, compare a new request after more than one check interval with bounded client/server logs; do not infer a precise lifetime from a single timestamp. If the application holds a long-lived request, observe it separately rather than treating it as an idle pooled session.［3］

A file edit does not promise live user removal. This isolated unit intentionally has no ExecReload: validate the configuration and use systemctl restart for a known interruption point. Do not advertise a generic reload command as immediate session revocation.

Step 5: Renew certificates, revoke access, and restore

Have the existing certificate workflow renew the chain and key, then install the matching pair with the same restrictive ownership. Check configuration as sbanytls, restart only this unit, and verify the intended identity and expiry through a fresh connection. The TLS documentation describes file reloading, but this procedure uses explicit restart and verification rather than treating file replacement as success.［4］

After a compromise, replace the affected password and restart the unit to interrupt its old connections. Confirm new credentials work and removed credentials fail. Only then consider sudo systemctl enable sing-box-anytls.service for automatic startup, followed by an authorized maintenance-window reboot check and a fresh request.

To retire the exercise, stop and disable its unit, stop the foreground client, and remove only its recorded firewall/provider allowance. Restore the browser proxy. Preserve necessary private diagnostics, then remove this exercise's unit and certificate/configuration copies and run sudo systemctl daemon-reload. Inspect the listener and verify original management and DNS behavior. Remove the package or APT source only if your baseline proves no other installation needs it. Stop further changes if recovery is not verified; use the independent management path.

Inspect the deployed certificate file with sudo openssl x509 -in /etc/sing-box-anytls/fullchain.pem -noout -subject -issuer -dates. This shows local identity and validity dates; combine it with a fresh TLS-verified client request, since reading a file alone does not prove which certificate a remote process serves.

After removing the exercise files, remove its newly created sbanytls account only after confirming that no remaining process, service unit, or file depends on its UID or group. Use sudo userdel sbanytls without force or home-directory removal; if its dedicated group remains and has no other members or dependencies, remove it with sudo groupdel sbanytls. Preserve pre-existing identities and stop if ownership is uncertain. Delete the owned anytls-client.json and negative-test copies when no longer needed; keep any necessary backups private and never reactivate revoked credentials.［7］［8］

Summary

Verify TLS identity before interpreting password or application failures.
Separate idle-session cleanup, fresh authentication, and existing-session interruption.
Restore the original service and client state with narrowly owned cleanup.

FAQ

Why not disable certificate verification to troubleshoot?

That removes the identity check you are trying to establish. Correct the server name, trust chain, time, or certificate deployment while keeping verification enabled.［4］

Can I reuse a Trojan configuration?

No. Use matching AnyTLS fields from this implementation. Shared use of TLS does not make different protocol profiles interchangeable.

Does deleting a user immediately disconnect existing traffic?

A file edit alone provides no such evidence. This procedure restarts its isolated service, then checks removed credentials on a fresh connection.

Are idle sessions the same as failed connections?

No. An unused pooled session can be cleaned up normally. Test whether a later new request can establish a healthy session before diagnosing an outage.［3］

Should I copy the minimum-idle value of five?

Not for this baseline. The documented default is zero; keep options omitted until you have a justified, separately checked reason to tune them.［3］

Does a successful browser request verify all traffic?

No. It verifies the tested browser path. Other applications, DNS, IPv6, and UDP require their own supported configuration and checks.

What if the new certificate fails after renewal?

Stop the exercise or restore a still-valid matching certificate pair and safe configuration. Verify fresh TLS and application requests before resuming, and never restore a compromised key.

Disclaimer: Administer only authorized hosts and networks and follow applicable law and policy. Expected observations are reader verification criteria, not an author test record or a guarantee of network availability.

Sources:

sing-box 1.14.3 release — https://github.com/SagerNet/sing-box/releases/tag/v1.14.3
sing-box AnyTLS inbound — https://sing-box.sagernet.org/configuration/inbound/anytls/
sing-box AnyTLS outbound — https://sing-box.sagernet.org/configuration/outbound/anytls/
sing-box TLS configuration — https://sing-box.sagernet.org/configuration/shared/tls/
sing-box package installation and service management — https://sing-box.sagernet.org/installation/package-manager/
sing-box local DNS server and route — https://sing-box.sagernet.org/configuration/dns/server/local/
Ubuntu Noble userdel manual — https://manpages.ubuntu.com/manpages/noble/man8/userdel.8.html
Ubuntu Noble groupdel manual — https://manpages.ubuntu.com/manpages/noble/man8/groupdel.8.html

Sources checked 11 October 2026.

Related Articles:

AnyTLS Server Setup with sing-box and Verified TLS