1
0

inbounds.mdx 3.7 KB

12345678910111213141516171819202122232425262728293031323334353637383940414243444546474849505152535455565758596061626364656667686970717273747576777879808182838485868788899091929394959697
  1. ---
  2. title: Inbounds & Protocols
  3. description: Create inbounds in 3x-ui — protocols, transports, traffic reset and expiry, and fallbacks that serve multiple protocols on one port.
  4. icon: ArrowDownToLine
  5. ---
  6. An **inbound** is a listener that accepts client connections on a port using a
  7. particular protocol and transport. Most of your day-to-day work is creating and
  8. managing inbounds and the clients inside them.
  9. ## Create an inbound
  10. <Steps>
  11. <Step>
  12. ### Add an inbound
  13. Open **Inbounds → Add**, give it a remark, pick a **protocol**, and choose a
  14. **port** and listen address.
  15. </Step>
  16. <Step>
  17. ### Choose a transport and security
  18. Pick the transport (TCP, WebSocket, gRPC, HTTPUpgrade, XHTTP, …) and the security
  19. layer (none, TLS, or REALITY). See [Transports](/docs/config/transports) and
  20. [REALITY](/docs/config/reality).
  21. </Step>
  22. <Step>
  23. ### Add clients
  24. Add one or more clients, each with its own credential, limits, and share link.
  25. See [Clients](/docs/config/clients).
  26. </Step>
  27. <Step>
  28. ### Set traffic limit, expiry, and reset
  29. Optionally cap total traffic and set an expiry date for the inbound, and choose a
  30. periodic **traffic reset** schedule: `never` (default), `hourly`, `daily`,
  31. `weekly`, or `monthly`.
  32. </Step>
  33. </Steps>
  34. ## Supported protocols
  35. The inbound editor accepts these protocols:
  36. | Protocol | Notes |
  37. | ---------------------- | ------------------------------------------------------------------------ |
  38. | **VLESS** | Lightweight; the basis for REALITY + XTLS-Vision. Recommended. |
  39. | **VMess** | Older but very widely supported by clients. |
  40. | **Trojan** | TLS-based; supports XTLS and fallbacks. |
  41. | **Shadowsocks** | Includes Shadowsocks-2022 (`2022-blake3-*`) ciphers. |
  42. | **WireGuard** | Modern tunnel. |
  43. | **Hysteria2** | Selected as `hysteria`; the panel emits `hysteria2://` links. |
  44. | **HTTP** | HTTP proxy. |
  45. | **Mixed (SOCKS/HTTP)** | A combined SOCKS + HTTP listener. |
  46. | **Dokodemo-door / Tunnel** | Port forwarding / traffic redirect. |
  47. | **MTProto** | Telegram MTProto proxy, served by a bundled `mtg` process (not Xray). |
  48. <Callout type="info">
  49. Hysteria2 isn't a separate protocol internally — it's the `hysteria` protocol
  50. with the transport version set to 2, and the panel generates `hysteria2://`
  51. share links for it.
  52. </Callout>
  53. ## Fallbacks — multiple protocols on one port
  54. Fallbacks let a single TLS port (e.g. `443`) serve more than one protocol — for
  55. example VLESS **and** Trojan — by routing unmatched handshakes to a child
  56. inbound. In 3x-ui, fallbacks are managed in the panel (a master inbound's
  57. **Fallbacks** list) rather than hand-written into JSON.
  58. Fallbacks are available only when the master inbound is:
  59. - **VLESS** or **Trojan**,
  60. - on the raw **TCP** transport,
  61. - with **TLS** or **REALITY** security.
  62. Each fallback rule targets a child inbound and can match on `path`, `alpn`, and
  63. `dest`. Client share links for a fallback child are automatically rewritten to
  64. advertise the master's address, port, and TLS.
  65. ## Not sure which to pick?
  66. Use the wizard to get a recommendation based on your goals and clients:
  67. <ProtocolWizard />
  68. <Callout type="info">
  69. For censorship resistance with modern clients, **VLESS + REALITY +
  70. XTLS-Vision** is the usual best choice — continue to
  71. [REALITY](/docs/config/reality).
  72. </Callout>