This Trojan proxy server setup uses Xray-core v26.3.27, a domain you control and a valid TLS certificate. It configures one restricted test entry, then separates successful proxy forwarding from TLS availability, wrong credentials, revocation and recovery; the author did not perform a complete end-to-end deployment experiment.

Key Takeaways

Stop if you cannot supply a legitimate domain, matching certificate and independent management path.

Use one fixed implementation; do not mix Trojan-gfw or Trojan-rs installation commands into Xray.

Keep certificate verification enabled and the local SOCKS entry on loopback.

A fallback website responding is not proof of proxy authentication.

Renewal, restart, credential revocation and rollback need independent acceptance checks.

When is this Trojan proxy server setup appropriate?

Read what running your own server commits you to before reserving a server. The reference is a dedicated, otherwise unused Ubuntu 24.04 LTS host and an independent authorized client running the same Xray release. This example forwards explicitly configured TCP applications; it does not establish device-wide DNS, IPv6, UDP or TUN coverage.

The Trojan protocol explanation covers the protocol separately. The protocol places a password-derived authentication value and request inside TLS.［1］ The pinned Xray implementation supports the fields below but emits a deprecation warning for Trojan; pinning documents this example, not a recommendation to ignore maintenance or future removals.［3］ Compare VLESS/REALITY and Trojan if your requirements or supported client differ.

Do not describe matching documentation as tested compatibility. Here the client is the matching official Xray core, avoiding assumptions about a third-party app's import format. Before using another client, verify its official protocol, transport, TLS name and authentication fields, then complete your own acceptance checks.

Step 1: Establish the domain, certificate and recovery boundary

Use a domain you own or are expressly authorized to operate, with the endpoint mapped to your server through your approved DNS process. Obtain a valid certificate for that name through your authorized issuer or ACME workflow. Certificate issuance varies by provider and is a prerequisite, not an invitation to borrow another website's identity or content.

Check the Trojan TLS certificate chain, validity dates, matching private key and renewal owner before opening a listener. If the domain or certificate is missing, expired or mismatched, stop this route. Do not repair it with insecure mode, skip verification, a shared secret from the Internet or a certificate for an unrelated name.

Inventory listeners, services, installer paths, firewall managers and the recovery console. Reserve server TCP 18443 and client loopback TCP 10808. The high server port avoids needing a privileged port, but runtime capabilities still require review. If Xray, its installation paths, the service identity or either port already belongs to another workload, stop this fresh-install procedure; arrange a separately reviewed migration instead.

Keep independent management available through the maintenance window. Restrict initial ingress to the authorized test client's address on both provider and host policy. An unrestricted outbound can reach what the host can reach: use an isolated host without sensitive internal routes, or implement a reviewed destination policy first. Authentication alone does not restrict destinations.

Step 2: Install the reviewed core and create minimal authentication

The official release tag is v26.3.27.［5］ Retrieve the official installation script as a file, review its downloads, file writes, service/user changes and removal behavior, and record its upstream revision. The installer itself rolls independently of the core tag. A shell syntax check does not establish trust.［6］

The following commands are reader instructions for the dedicated host, not actions performed by the author. Proceed with privileged installation only after reviewing the script and confirming the unused paths and identity:

curl --fail --location --proto '=https' --proto-redir '=https' \
  --output install-release.sh \
  https://raw.githubusercontent.com/XTLS/Xray-install/main/install-release.sh
less install-release.sh
bash -n install-release.sh
sudo adduser --system --group --no-create-home xray-lab
sudo bash install-release.sh install --version v26.3.27 --install-user xray-lab
sudo systemctl disable --now xray.service
sudo systemctl is-enabled xray.service
/usr/local/bin/xray version
sudo systemctl cat xray.service

Fresh installation starts and enables the unit. disable --now stops it and removes boot enablement; expect the enablement check to report disabled. Confirm /usr/local/bin/xray, /usr/local/etc/xray/config.json and runtime user xray-lab in the actual unit. Unexpected paths, a root runtime or a different version are stop conditions, not reasons to continue with guessed defaults.

Generate a unique high-entropy disposable password in a private terminal, for example with openssl rand -hex 32. Store it in protected configuration, not shell arguments, screenshots or tickets. Use separate credentials per device later so revocation has a clear target. The tag uses inbound clients[].password; no VLESS UUID, Vision flow or REALITY key belongs in this Trojan example.［3］

Step 3: Configure the listener and a matching local client

Replace every uppercase placeholder in the server JSON. SERVER_LISTEN_IPV4 must be locally assigned; a provider's NAT public address is not necessarily bindable. Store the certificate chain and private key at the indicated private paths, readable by xray-lab, with directories root:xray-lab mode 750 and files mode 640. Do not relax issuer directories globally to solve permissions; deploy dedicated protected copies through the renewal owner.

{
  "log": {"access": "none", "loglevel": "warning"},
  "inbounds": [{
    "tag": "trojan-lab", "listen": "SERVER_LISTEN_IPV4", "port": 18443,
    "protocol": "trojan",
    "settings": {"clients": [{"password": "DISPOSABLE_PASSWORD", "email": "lab-device"}]},
    "streamSettings": {
      "network": "raw", "security": "tls",
      "tlsSettings": {"certificates": [{
        "certificateFile": "/usr/local/etc/xray/tls/fullchain.pem",
        "keyFile": "/usr/local/etc/xray/tls/privkey.pem"
      }]}
    }
  }],
  "outbounds": [{"protocol": "freedom", "tag": "direct"}]
}

Protect the configuration as root:xray-lab mode 640 and its directory mode 750. Test with sudo -u xray-lab /usr/local/bin/xray run -test -config /usr/local/etc/xray/config.json, then start only the dedicated xray.service and inspect ss -lntp. Syntax acceptance does not prove listener availability, authentication or forwarding. Open only the reviewed TCP ingress rule; preserve management policy.

The inbound documentation describes Trojan and optional fallback behavior.［2］ This minimal example intentionally has no fallback. For the chosen tag, raw, TLS certificate paths and client serverName are supported by the pinned transport parser.［4］ Do not add another implementation's fields or disable trust verification to suppress an error.

On an isolated authorized client, save the following as private client.json, replacing the endpoint domain and same password. PROXY_DOMAIN must match the certificate. The loopback SOCKS listener is TCP only; another local user could reach an unauthenticated loopback entry on a shared machine, so use an isolated client or reviewed local access controls.［8］

{
  "log": {"access": "none", "loglevel": "warning"},
  "inbounds": [{
    "listen": "127.0.0.1", "port": 10808, "protocol": "socks",
    "settings": {"auth": "noauth", "udp": false}
  }],
  "outbounds": [{
    "protocol": "trojan",
    "settings": {"address": "PROXY_DOMAIN", "port": 18443, "password": "DISPOSABLE_PASSWORD"},
    "streamSettings": {
      "network": "raw", "security": "tls",
      "tlsSettings": {"serverName": "PROXY_DOMAIN"}
    }
  }]
}

Restrict client.json to its owner with mode 600, confirm xray version, validate with xray run -test -config client.json, then run xray run -config client.json in the private foreground terminal. Keep other network clients untouched. If loopback 10808 is occupied, do not kill its owner; select an unused port consistently in this test's configuration and request.

Step 4: Verify TLS, correct credentials and rejection separately

From the authorized client, substitute your real domain in this certificate check. OpenSSL documents hostname verification and returning verification errors.［7］ This establishes TLS evidence only, not Trojan authentication:

openssl s_client -connect PROXY_DOMAIN:18443 -servername PROXY_DOMAIN \
  -verify_hostname PROXY_DOMAIN -verify_return_error </dev/null

Inspect the chain, name, dates and verification result. Stop at any trust or name failure and repair the authorized certificate deployment. Do not use a no-verify option. To test proxy forwarding, replace the authorized task hostname and path below with a destination you control or may access, then correlate its own request evidence:

curl --fail --socks5-hostname 127.0.0.1:10808 https://AUTHORIZED_TASK_HOST/task

--socks5-hostname asks the SOCKS side to resolve the target name; it does not change device-wide DNS.［9］ For a deliberate Internet-exit check, inspect the visible exit address through the explicitly configured test application, then separately examine DNS, IPv6 and failure policy. Do not infer full-device coverage from this TCP example.

Check	Reader method	Expected outcome, not an observed result
Correct identity	Fresh request with the matching password and valid TLS	Authorized task reaches its destination through the intended proxy
Wrong password	Change only the disposable client password, restart that foreground client, request again	No authenticated forwarding of the task
Wrong certificate name	Restore password, change only the client's `serverName` to an unrelated name, restart the test client and issue a fresh request	TLS verification rejects; no task forwarding
Restore baseline	Restore correct name/password and restart the test client	The original permitted task works again
Fallback, if separately configured	Inspect owned fallback response independently of proxy task evidence	Website availability is not counted as proxy login

After each client configuration change, stop only the foreground Xray process started for this test, validate with xray run -test -config client.json, restart with xray run -config client.json, and issue a fresh task request. Editing the file does not reload the running process.［10］ For the wrong-name case, confirm a certificate-name verification error in the private client output; a timeout or authentication failure alone is inconclusive.

The domain used as the wrong name need not be contacted: keep the endpoint fixed and change only TLS verification identity. If the negative case forwards the task, close the new exposure and inspect the active configuration and client capture before continuing. No failed case is fixed by accepting invalid certificates.

Step 5: Renew, restart, revoke and restore

Assign certificate renewal to a named operator and document expiry monitoring and an authorized renewal rehearsal. After successful issuance, deploy the matching chain/key with the same restricted ownership, validate as the service identity and apply through the dedicated unit. Verify the served certificate independently from the client and repeat a fresh authorized task. A renewed file on disk alone does not prove the live service serves it.

For boot persistence, enable the unit only after positive and negative checks, confirm its enablement, and use an authorized reboot window to recheck version, paths, identity, listener and fresh forwarding. If no reboot is authorized, boot persistence remains unverified. Rebooting is not required to understand this procedure.

To revoke a device, remove its password entry from persistent server configuration, validate, and restart this dedicated instance during an approved interruption. Restart terminates all its sessions, not only the removed device. Retry the old password on a fresh connection; it must not forward. Create a new disposable password for any further test and confirm both new acceptance and old rejection. Removing a client file or subscription is not server revocation.

If renewal, restart or a configuration change fails, close only the new ingress exposure and restore the previous compatible binary/configuration and still-valid certificate pair. Never restore a compromised password or revoked private key from backup. Verify the original management path and original services before another attempt. If no valid certificate remains, keep the proxy unavailable until trust is repaired.

At the decision about ongoing certificate and service ownership, compare VPS operation with a managed VPN service. This does not claim that a managed app imports Trojan or administers this server. For bounded failure evidence, use Xray server log handling, then restore temporary logging.

After a disposable deployment experiment, revoke test credentials, stop and disable only its unit, remove its owned ingress rules and remove only resources recorded in the initial inventory. Review the retained installer's removal behavior before using it; shared paths are a stop condition. Independently confirm the pre-experiment services and management, rather than treating a stop command as proof of cleanup.

Summary

Require a legitimate domain, valid TLS and independent management first.
Pin one reviewed Xray implementation and keep secrets private.
Validate TLS, authorized forwarding and negative cases independently.
Confirm renewal and revocation in the running service, including fresh connections.
Restore only compatible trusted state and verify removal of owned test resources.

FAQ

Can I deploy without my own authorized domain and certificate?

Not through this route. Supply a legitimate domain and valid matching certificate before exposure. An unrelated website name, insecure option or shared public credential does not satisfy the prerequisite; stop and choose a separately supported approach.

Can I combine Trojan-rs instructions with this JSON?

No. The example is Xray-core v26.3.27 on both ends. Installation paths, fields and service behavior belong to that implementation. Another client's official documentation must match the protocol and TLS requirements before separate compatibility testing.

Does seeing the fallback website prove the proxy works?

No. A TLS or web response can exist without authenticated proxy forwarding. Use the explicit client request and the authorized task destination's evidence. This minimal server has no fallback; adding one creates another separately reviewed path.

What should happen with an incorrect password?

A fresh request must not forward the authorized task through the proxy. Change only the disposable password, restart the test client, and distinguish rejection from any fallback response. If forwarding succeeds, stop exposure and inspect active state before proceeding.

May I disable certificate checks to diagnose an error?

No. Inspect name, chain, dates, key pairing and served certificate while verification stays enabled. A certificate error is a stop condition. Use the wrong-name negative case to prove rejection, not to justify bypassing it.

Does deleting a subscription revoke the server password?

No. Remove the server-side client entry, validate, restart the dedicated instance with awareness of all-session interruption, and retry the old identity on a fresh connection. Keep compromised credentials out of rollback backups.

What if renewal leaves no valid certificate?

Keep the proxy unavailable and repair trust through the authorized issuer workflow. Restore an earlier pair only if it is still valid and uncompromised. Recheck the live served certificate and fresh forwarding; files existing on disk are insufficient.

Disclaimer: This is a documentation-based procedure, not an author-tested deployment or compatibility guarantee. Operate only authorized resources and destinations, comply with law and provider terms, and stop when domain ownership, certificate trust, scope or recovery cannot be established.

Sources:

The Trojan Protocol https://trojan-gfw.github.io/trojan/protocol.html
Trojan — Xray inbound configuration https://xtls.github.io/en/config/inbounds/trojan.html
Xray-core v26.3.27 Trojan configuration implementation https://github.com/XTLS/Xray-core/blob/v26.3.27/infra/conf/trojan.go
Xray-core v26.3.27 TLS configuration implementation https://github.com/XTLS/Xray-core/blob/v26.3.27/infra/conf/transport_internet.go
Xray-core v26.3.27 release https://github.com/XTLS/Xray-core/releases/tag/v26.3.27
Xray-install — official installer https://github.com/XTLS/Xray-install
openssl-s_client — OpenSSL 3.0 documentation https://docs.openssl.org/3.0/man1/openssl-s_client/
SOCKS — Xray inbound configuration https://xtls.github.io/en/config/inbounds/socks.html
curl — command-line manual https://curl.se/docs/manpage.html
Xray-core v26.3.27 startup and configuration loading https://github.com/XTLS/Xray-core/blob/v26.3.27/main/run.go

Sources checked 11 October 2026.

Trojan Proxy Server Setup: Certificates and Verification