[Bug]: Connection Refused After Fresh Reinstall and Clean 3X-UI Installation

[alinasrollahzadeh405-sudo]

Describe the bug

Hello,

I am experiencing a recurring issue with 3X-UI.

Server information:

• Ubuntu 22.04
• Fresh VPS rebuild
• Fresh 3X-UI installation
• VLESS + Reality

Problem:
After some time, I can no longer access the panel in the browser and receive a "Connection Refused" error.

To troubleshoot, I completely rebuilt the VPS and reinstalled Ubuntu and 3X-UI from scratch. However, the same problem occurred again after the clean installation.

Additional notes:

• SSH access remains available when the issue happens.
• The VPS itself is online and reachable.
• Rebuilding the server did not resolve the issue.
• In previous cases, using the "Update Menu" option sometimes temporarily fixed the problem.

I would appreciate any suggestions on how to diagnose this issue or determine whether it is related to 3X-UI, Xray, or panel services.

Thank you.

How to reproduce the problem

1. Install Ubuntu 22.04 on a fresh VPS.
2. Install 3X-UI with default settings.
3. Create and use VLESS + Reality inbound.
4. Use the server normally for some time.
5. Try to access the 3X-UI panel from a browser.
6. The panel becomes inaccessible and the browser shows "Connection Refused".
7. Rebuilding the VPS and reinstalling 3X-UI does not permanently solve the issue.

Expected behavior

No response

Actual behavior

No response

Relevant logs

Screenshots

No response

3x-ui version

3.2.7

Xray-core version

No response

How did you install 3x-ui?

install.sh script

Operating system

ubuntu22.04

Which parts of the panel are affected?

No response

Browser (only if it is a UI bug)

No response

Is the panel behind a reverse proxy or CDN?

None

Before submitting

• I searched existing issues and this bug has not been reported.
• I am running the latest released version of 3x-ui (or have verified the bug still exists on it).
• This bug report is written in English.
• I have redacted any sensitive data (tokens, real domains, client UUIDs).

[github-actions]

Thanks for the detailed report. "Connection Refused" means nothing is listening on the panel port — the x-ui process itself has stopped or never restarted. This is distinct from a firewall drop (which shows as a timeout). Here is a structured way to diagnose it the next time it happens, based on how the service is wired in this repo.

---

Step 1 — Check the service state immediately when it fails

systemctl status x-ui

The most important line is the Active: field. You will see one of:

State	Meaning
active (running)	Process is up — the issue is a firewall/port mismatch, not a crash
failed (Result: start-limit-hit)	Crashed too many times; systemd stopped restarting it
failed (Result: exit-code)	Crashed and has not hit the limit yet
inactive (dead)	Stopped cleanly (e.g., manual systemctl stop)

Step 2 — Read the actual crash reason

journalctl -u x-ui -n 100 --no-pager

This shows log.Fatalf output from main.go and any Go panic stack traces. Please paste this output in a follow-up comment — it is the single most useful piece of information for diagnosing the root cause.

Step 3 — Check for OOM kills

Many cheap VPS instances with 512 MB–1 GB RAM run out of memory under combined Xray + panel load. The kernel OOM killer silently terminates the process and leaves a kernel log message:

dmesg | grep -iE "killed|oom" | tail -20

If you see lines like Out of memory: Kill process ... (x-ui), this is the cause.

Step 4 — Check the start-limit situation

The service file (x-ui.service.debian) has Restart=on-failure with no StartLimitIntervalSec override, so systemd applies its default (5 restart attempts per 10 seconds). If x-ui crashes faster than that, the unit enters the permanent failed state and will not restart automatically until you run:

systemctl reset-failed x-ui
systemctl start x-ui

This would also explain why "Update Menu" sometimes appeared to fix the issue — rerunning any management command that calls systemctl restart can work from the failed state in some systemd versions.

Step 5 — Confirm the port is actually in use (or not)

When the issue is active, check whether anything is listening on port 2053 (the default panel port):

ss -tlnp | grep 2053

If nothing appears, x-ui is not running. If something else appears, there is a port conflict.

---

What to share here

To identify the root cause please provide the output of these commands while the panel is inaccessible:

1. systemctl status x-ui
2. journalctl -u x-ui -n 100 --no-pager
3. dmesg | grep -iE "killed|oom" | tail -20
4. ss -tlnp | grep 2053
5. How much RAM does the VPS have? (free -h)
6. The Xray-core version (x-ui → option to show settings, or journalctl -u x-ui | grep -i xray | head -5)

With those details the actual failure path should be clear.