xTor manages multiple local Tor client workers. It can make Tor routing easier to operate, but it does not make every application anonymous and cannot guarantee a country, IP address, speed, uptime, reachability, or legal outcome. The server operator remains responsible for the installation and all traffic routed through it.

• Obtain permission from the hosting provider, reseller, network owner, and system administrator. Do not assume that paying for a VPS automatically permits Tor traffic.
• Read and follow local laws, the provider's acceptable-use policy, bandwidth rules, and the terms of every destination service you access.
• Confirm that you can receive and respond to abuse reports or complaints for the server.
• Keep administrative access, the operating system, Tor, and xTor maintained and backed up.

If any applicable policy or authority forbids the intended use, do not run xTor there.

Tor connectivity is outside xTor's control. An ISP, hosting provider, firewall, the Tor network, an exit relay, or a destination service may block, filter, throttle, rate-limit, or restrict traffic. Some destinations reject all Tor exits, particular exit IP addresses, or particular destination ports.

Catalogue availability and an observed exit country are point-in-time results. They can change as relays and circuits change. Force Start retries a requested country preference, but it cannot create a suitable relay or guarantee that the requested country will be obtained.

xTor's managed SOCKS endpoints are intended to bind to 127.0.0.1 only.

• Never expose a SOCKS port on 0.0.0.0, ::, a public IP address, or an untrusted LAN.
• Do not publish xTor as an open proxy or give untrusted users access to its listeners.
• xTor does not add user authentication or network access control to its SOCKS endpoints.
• Loopback binding does not isolate mutually untrusted users who already share access to the same host.

Use host firewall rules, account separation, and normal server hardening as additional controls. Do not weaken the loopback boundary to make remote access more convenient.

Configuring one proxy field does not prove that every connection from an application uses Tor.

• Use socks5h or an equivalent remote-DNS option so hostnames are resolved through the SOCKS route.
• Check whether the application can bypass the proxy through local DNS, direct TCP fallback, UDP, IPv6, telemetry, update services, helper processes, or embedded components.
• Test the application's actual traffic path, not only xTor's worker status.
• Keep HTTPS/TLS enabled. A Tor exit can observe unencrypted traffic.
• Treat browser fingerprinting, account identity, cookies, downloads, and endpoint compromise as separate risks.

xTor is not a VPN, a transparent whole-system tunnel, or a replacement for the privacy protections and browser hardening provided by Tor Browser.

Every active location runs an independent Tor process and consumes memory, CPU, file descriptors, sockets, and bandwidth. Actual use depends on traffic volume, circuit activity, Tor behavior, and the host. Monitor the server and start only as many locations as it can support safely.

Starting, stopping, restarting, Force Starting, changing a port, switching a profile, updating, rolling back, watchdog recovery, or uninstalling can interrupt active streams. Applications must tolerate connection loss and must not assume that a SOCKS session survives an operator action.

The first-install catalogue refresh and later node/location refreshes require outbound HTTPS access. Filtering, DNS failure, clock problems, certificate errors, or source unavailability can prevent a refresh. A stale catalogue does not guarantee that a listed route still works.

• Install xTor only from the official repository and release assets.
• Verify the published SHA-256 checksum before using an offline bundle.
• Keep the operating system, Tor package, CA certificates, and xTor updated.
• Back up important configuration and state before maintenance.
• Review update results and run sudo xtor doctor after unexpected behavior.

xTor retains the last valid catalogue when a new response fails validation, but that safety behavior does not make old relay data current.

Restrict access to /var/lib/xtor, Tor instance data, control cookies, system journals, bridge details, API credentials, SSH keys, and any other secrets on the host. Profile names, selected countries, port assignments, timestamps, diagnostics, and observed IP addresses may also reveal sensitive operational information.

Before sharing a log or screenshot:

1. Remove credentials, tokens, keys, cookies, hostnames, and public IP addresses.
2. Remove information that identifies users, applications, profiles, or traffic timing.
3. Rotate any credential that was exposed, even if the post or message was deleted afterward.

Do not use xTor for:

• a public or unauthenticated proxy service;
• abuse, intrusion, harassment, unsolicited traffic, evasion of lawful access controls, or any unlawful activity;
• torrent/P2P traffic or other workloads prohibited by the provider or Tor exit policies;
• aggressive mass circuit rotation, scraping, credential attacks, or activity likely to harm Tor, destination services, or other users.

xTor operates Tor clients. It does not turn the server into a Tor relay, bridge, or exit node.

By operating xTor, you accept responsibility for permission, access control, host security, monitoring, backups, resource limits, policy compliance, abuse handling, and all traffic routed through the installation. Stop using the project if you cannot meet those requirements or if the provider, network owner, destination service, or applicable law prohibits the intended use.