How to Configure Xray-Core Inbounds and Outbounds: A Complete Tutorial

The Anatomy of an Xray-core Configuration

At its heart, Xray-core is controlled by a single JSON file, typically named `config.json`. This file defines every aspect of its behavior. Understanding its main components is the first step towards mastery.

Inbounds vs. Outbounds: The Gateway and the Exit

Think of Xray-core as a processing box for your network traffic. Inbounds are the doors where traffic enters the box, and outbounds are the doors where it exits.

• Inbounds: These handlers listen for incoming connections. On a server, an inbound handler accepts connections from clients (e.g., using the VLESS protocol). On a client machine, an inbound handler creates a local proxy (like SOCKS or HTTP) that your applications connect to.
• Outbounds: These handlers are responsible for sending traffic out. On a client machine, the main outbound connects to your remote Xray server. Xray also has two special built-in outbounds: `freedom` (which sends traffic directly to its destination, bypassing any proxy) and `blackhole` (which silently drops traffic).

Protocols: VLESS, VMess, and Trojan

The protocol defines the language spoken between the client and server. Xray-core supports several, but three are most common:

Routing: The Traffic Director

The `routing` object is the brain of your Xray-core setup. It examines each connection and decides which outbound to send it to based on a set of rules you define. This allows for powerful policies like blocking ads, bypassing domestic websites, or routing specific traffic through different servers.

Connecting to Your Server (Client-Side Outbound)

Now let's configure the client machine (e.g., your laptop or desktop) to connect to the server we just set up. The client configuration has two main parts: an inbound to accept local connections from your apps (like a web browser) and an outbound to send that traffic to your server.

Example Client `config.json`

{
  "log": {
    "loglevel": "warning"
  },
  "inbounds": [
    {
      "port": 10808,
      "listen": "127.0.0.1",
      "protocol": "socks",
      "settings": {
        "auth": "noauth",
        "udp": true
      }
    }
  ],
  "outbounds": [
    {
      "protocol": "vless",
      "settings": {
        "vnext": [
          {
            "address": "your.domain.com", // Your server's domain
            "port": 443,
            "users": [
              {
                "id": "YOUR_UUID_HERE", // Must match the server's UUID
                "flow": "xtls-rprx-direct",
                "encryption": "none"
              }
            ]
          }
        ]
      },
      "streamSettings": {
        "network": "tcp",
        "security": "tls",
        "tlsSettings": {
          "serverName": "your.domain.com" // Your server's domain
        }
      }
    },
    {
      "protocol": "freedom",
      "tag": "direct"
    }
  ]
}

Configuration Breakdown

• `inbounds`: We create a SOCKS5 proxy listening on port `10808` on the local machine (`127.0.0.1`). This is the proxy address you'll configure in your web browser or system settings. `udp: true` enables UDP forwarding, which is important for some applications.
• `outbounds`: This is where we define the connection to our remote server.
• `settings.vnext`: This array contains the server details. `address` must be your server's domain name, and `port` must match the server's inbound port (`443`).
• `users.id`: This UUID **must be identical** to the one you set in the server's configuration.
• `streamSettings`: These settings must match the server's stream settings. `security` is `tls`, and critically, `tlsSettings.serverName` must be set to your domain to ensure the TLS handshake succeeds.

Organizing Your Configuration with Overrides

As your configuration grows, a single `config.json` file can become unwieldy. Xray-core provides a powerful solution: the ability to split your configuration into multiple files within a directory.

You can start Xray by pointing it to a directory instead of a single file using the `-confdir` flag: `xray -confdir /path/to/config/dir`.

Xray will load all `.json` files in that directory in alphabetical order and merge them. This allows you to separate logical parts of your configuration.

Example Directory Structure

/etc/xray/
├── 00_log.json
├── 05_inbounds.json
├── 06_outbounds.json
└── 99_routing.json

Here's how it works:

• Merging Objects: Top-level objects like `log` or `routing` are merged. If `99_routing.json` defines a `routing` object, it will be merged with any `routing` object defined in a previous file.
• Appending to Arrays: For arrays like `inbounds`, `outbounds`, and `routing.rules`, the contents of the array in a later file are **appended** to the contents from an earlier file. This allows you to define base outbounds in one file and add more in another.

For example, `05_inbounds.json` would contain only the `inbounds` array, and `99_routing.json` would contain only the `routing` object. This modular approach makes managing complex setups significantly easier and less error-prone.

Conclusion

You have now journeyed through the fundamentals and advanced features of Xray-core configuration. We've covered the critical roles of inbounds and outbounds, configured a secure VLESS server and client, mastered traffic control with routing rules, and learned how to keep configurations tidy with the override mechanism.

Xray-core is an exceptionally versatile tool, and what we've explored here is just the beginning. We encourage you to experiment with different protocols, transports, and routing rules to tailor a setup that perfectly fits your needs. For further details and an exhaustive list of all options, the