3x-ui/README.ar_EG.md at cc3303dd8cdd3959faada997f2c2aeb31e894499

mirror of https://github.com/MHSanaei/3x-ui.git synced 2026-07-08 13:46:08 +00:00

Files

T

Sanaei 6214ff4edc fix(mtproto): stop dropping connections on client/inbound edits; add live updates + ad-tag (#5838 )

* fix(mtproto): split the mtg fingerprint into structural and secrets parts

A reordered clients array in the stored settings used to read as a config
change because the fingerprint concatenated secrets in array order, and one
opaque fingerprint could not tell a restart-worthy change (bind address,
fronting, throttle) from a secret-set change a reload-capable mtg can absorb
in place. Sort the secret pairs so order stops mattering, and split the value
so the upcoming hot-reload path can decide between keeping, reloading, and
restarting the process.

* fix(mtproto): stop restarting mtg on every inbound edit

Saving an mtproto inbound tore down and respawned its mtg sidecar even when
nothing material changed, dropping every live Telegram connection: the update
path pushed DelInbound+AddInbound, and Remove deletes the manager's map entry,
so Ensure's fingerprint no-op gate could never fire. Route mtproto updates
through a single Ensure call so an edit that leaves the generated TOML alone
keeps the process, and only real config changes restart it.

Capturing the pre-edit protocol also fixes a latent leak: changing an
inbound's protocol away from mtproto never stopped the sidecar, because the
snapshot handed to the runtime already carried the new protocol and the
removal took the xray branch, leaving an orphaned mtg holding the port.

An mtproto push failure no longer requests an xray restart - xray cannot fix
the sidecar, and the 10s reconcile job self-heals it.

The regression test fakes mtg by re-executing the test binary, counting
spawns through a pid file: an unchanged save and a remark-only edit must keep
the process, a re-keyed secret must restart it.

* fix(mtproto): exclude depleted clients from the reconcile job to match the sync push

The 10s reconcile job derived mtg secret sets from raw inbound settings while
the interactive push filtered clients through buildRuntimeInboundForAPI, which
drops client_traffics-disabled (depleted or expired) clients. The two paths
therefore disagreed on the fingerprint - each disagreement one needless mtg
restart dropping live connections - and worse, the job kept serving depleted
clients' secrets indefinitely, so running out of traffic never actually cut an
mtproto client's access.

DesiredMtprotoInstances now builds the job's desired state with the same
depletion overlay the push uses (one bulk client_traffics query), drops
inbounds whose every secret is filtered away so their sidecar stops, and
AddInbound pushes the filtered payload too so an imported inbound carrying
disabled stats does not seed a fingerprint the next reconcile disagrees with.

* feat(mtproto): hot-reload mtg secrets in place instead of restarting

A client add, removal, re-key, or enable-toggle changes only the [secrets]
section of the generated config, yet the panel could apply it only by killing
and respawning the mtg sidecar, dropping every Telegram connection on that
inbound. Split the ensure decision three ways: an identical config is a no-op,
a secrets-only change rewrites the TOML on the same api port and asks mtg to
hot-swap it via POST /reload, and a structural change (or a failed reload)
falls back to the full stop-and-start.

The reload endpoint is served by the mhsanaei/mtg-multi fork; against an older
binary the POST 404s and the manager restarts exactly as before, so panel and
binary upgrades stay order-independent.

* feat(mtproto): apply single-client edits to the sidecar immediately

Client CRUD on an mtproto inbound was a runtime no-op, so an add, delete,
re-key, or enable-toggle only reached mtg on the next 10s reconcile. With the
sidecar now able to hot-reload, push the change straight after the edit commits:
applyLocalMtproto rebuilds the inbound's filtered client set and re-applies it,
so a new client works within a moment (and, on a reload-capable binary, without
disturbing the others) and deleting the last client stops the process.

The three interactive single-client paths (add, update, delete) call it; bulk
operations still ride the reconcile job, which converges to the same state.

* chore(mtproto): pin mtg-multi to the mhsanaei fork v1.13.3

The reload endpoint the panel now uses lives in the mhsanaei/mtg-multi fork, so
point the source-build pin (DockerInit.sh + both release.yml matrices) at it and
bump to v1.13.3. The install still produces the same mtg-multi binary name, so
the mtg-<os>-<arch> rename and everything downstream are unchanged. Docs and the
package comment note the hot-reload path and its restart fallback.

* feat(mtproto): apply live secret updates via the management API and add ad-tag

Two capabilities the mhsanaei/mtg-multi v1.13.3 fork exposes are now surfaced by
the sidecar manager.

Live updates go through PUT /secrets on the fork's management API instead of
POST /reload: the panel already holds the whole desired set per inbound, so it
sends secrets and the advertising tag as one JSON call that mtg applies
atomically, keeping every unchanged connection and closing only removed or
re-keyed ones. The config file is still written first so a restart or crash
recovery reproduces the state, and any non-200 (an older binary, a refused
connection) still falls back to a full restart.

Per-inbound ad-tag adds an optional 32-hex Telegram advertising tag plus
public-ipv4/public-ipv6 overrides. The ad-tag rides the reloadable secrets
fingerprint, so changing it hot-applies without dropping connections; the public
IPs are proxy-construction parameters and sit in the structural fingerprint, so a
change there restarts the process. Empty public IPs are omitted so mtg
auto-detects the reachable address.

* feat(inbounds): expose the mtproto ad-tag and public IP in the inbound form

Adds an Ad-tag field (validated as 32 hex characters) plus optional Public IPv4
and Public IPv6 overrides to the MTProto inbound form, backed by the same-named
settings the sidecar writes into the mtg config. The public IPs are optional —
left blank, mtg auto-detects the reachable address the ad-tag middle proxy needs.
English strings are added to every locale; the non-English ones carry the
English text until translated and fall back to it meanwhile.

* ci(mtproto): install mtg-multi from prebuilt release binaries

The fork now publishes release archives for every platform we package, so
download and unpack the matching mtg-multi-<ver>-<os>-<arch> binary instead of
compiling it from source with go install. Faster builds and no toolchain step,
and the archive's platform labels line up with our matrix; the produced
mtg-<os>-<arch> filenames are unchanged.

* i18n(mtproto): localize the ad-tag and public IP strings

The six mtgAdTag*/mtgPublicIp* keys shipped with English text in every locale as
a placeholder. Translate them into the twelve non-English locales (Arabic,
Spanish, Persian, Indonesian, Japanese, Portuguese-BR, Russian, Turkish,
Ukrainian, Vietnamese, and Simplified/Traditional Chinese); en-US is unchanged.

* retired goreportcard.com

2026-07-07 01:13:24 +02:00

13 KiB

Raw Blame History

3X-UI هي لوحة تحكم ويب متقدمة ومفتوحة المصدر لإدارة خوادم Xray-core. توفّر واجهة نظيفة ومتعددة اللغات لنشر وتكوين ومراقبة مجموعة واسعة من بروتوكولات الوكيل وVPN — من خادم VPS واحد إلى عمليات النشر متعددة العقد.

تم بناء 3X-UI كنسخة محسّنة (fork) من مشروع X-UI الأصلي، وتضيف دعمًا أوسع للبروتوكولات، واستقرارًا محسّنًا، ومحاسبة للترافيك لكل عميل، والعديد من ميزات تحسين تجربة الاستخدام.

Important

هذا المشروع مخصص للاستخدام الشخصي فقط. يرجى عدم استخدامه لأغراض غير قانونية أو في بيئة إنتاجية.

الميزات

اتصالات واردة متعددة البروتوكولات — VLESS، VMess، Trojan، Shadowsocks، WireGuard، Hysteria2، HTTP، SOCKS (Mixed)، Dokodemo-door / Tunnel و TUN.
وسائل نقل وأمان حديثة — TCP (Raw)، mKCP، WebSocket، gRPC، HTTPUpgrade و XHTTP، مؤمَّنة بـ TLS و XTLS و REALITY.
Fallback — تقديم عدة بروتوكولات على منفذ واحد (مثل VLESS و Trojan على المنفذ 443) باستخدام ميزة fallback في Xray.
إدارة لكل عميل — حصص الترافيك، تواريخ انتهاء الصلاحية، حدود IP، حالة الاتصال المباشرة، وروابط مشاركة وأكواد QR واشتراكات بنقرة واحدة.
إحصائيات الترافيك — لكل اتصال وارد، ولكل عميل، ولكل اتصال صادر، مع عناصر تحكم لإعادة التعيين.
دعم العقد المتعددة — إدارة وتوسيع عبر عدة خوادم من لوحة واحدة.
الاتصالات الصادرة والتوجيه — WARP، NordVPN، قواعد توجيه مخصصة، موازنات تحميل، وتسلسل الوكلاء الصادرة.
خادم اشتراك مدمج بصيغ إخراج متعددة وقوالب صفحات مخصصة.
روبوت تيليجرام للمراقبة والإدارة عن بُعد.
واجهة RESTful API مع توثيق Swagger داخل اللوحة.
تخزين مرن — SQLite (افتراضي) أو PostgreSQL.
13 لغة لواجهة المستخدم مع سمات داكنة وفاتحة.
تكامل مع Fail2ban لفرض حدود IP لكل عميل.

لقطات الشاشة

انقر للتوسيع

البدء السريع

bash <(curl -Ls https://raw.githubusercontent.com/mhsanaei/3x-ui/master/install.sh)

لتثبيت إصدار محدد، أضِف وسمه (مثل v3.4.0):

bash <(curl -Ls https://raw.githubusercontent.com/mhsanaei/3x-ui/master/install.sh) v3.4.0

لتثبيت بنية dev المتجددة (أحدث إصدار أولي لكل التزام (commit) من main، وليس إصدارًا مستقرًا)، مرّر dev-latest:

bash <(curl -Ls https://raw.githubusercontent.com/mhsanaei/3x-ui/master/install.sh) dev-latest

أثناء التثبيت، يتم إنشاء اسم مستخدم وكلمة مرور ومسار وصول عشوائية. بعد التثبيت، شغّل x-ui لفتح قائمة الإدارة، حيث يمكنك بدء/إيقاف الخدمة، وعرض أو إعادة تعيين بيانات تسجيل الدخول، وإدارة شهادات SSL، والمزيد.

للحصول على الوثائق الكاملة، يرجى زيارة ويكي المشروع.

التثبيت غير التفاعلي

يعمل المثبِّت أيضًا بشكل غير تفاعلي لـ cloud-init. عيّن XUI_NONINTERACTIVE=1 (أو مرّره عبر أنبوب دون TTY) وسيتولى التثبيت من البداية إلى النهاية دون أي مطالبات، مُنشئًا بيانات اعتماد عشوائية وكاتبًا إياها في /etc/x-ui/install-result.env. راجع deploy/ لـ:

بيانات مستخدم cloud-init — تثبيت غير تفاعلي على أي سحابة (Hetzner/AWS/DO/Vultr/GCP/Azure/Oracle)
ملاحظات Hetzner Cloud — نشر يعتمد على cloud-init على Hetzner

المنصات المدعومة

أنظمة التشغيل: Ubuntu، Debian، Armbian، Fedora، CentOS، RHEL، AlmaLinux، Rocky Linux، Oracle Linux، Amazon Linux، Virtuozzo، Arch، Manjaro، Parch، openSUSE (Tumbleweed / Leap)، Alpine و Windows.

المعماريات: amd64 · 386 · arm64 (aarch64) · armv7 · armv6 · armv5 · s390x.

خيارات قاعدة البيانات

يدعم 3X-UI خلفيتين (backends) يتم اختيارهما أثناء التثبيت:

SQLite (افتراضي) — ملف واحد في /etc/x-ui/x-ui.db. بدون إعداد، مثالي لعمليات النشر الصغيرة والمتوسطة.
PostgreSQL — موصى به لأعداد العملاء الكبيرة أو الإعدادات متعددة العقد. يمكن للمثبِّت تثبيت PostgreSQL محليًا لك، أو قبول DSN لخادم موجود.

في وقت التشغيل، يتم اختيار الخلفية عبر متغيرات البيئة (يكتبها المثبِّت لك في /etc/default/x-ui):

XUI_DB_TYPE=postgres
XUI_DB_DSN=postgres://xui:password@127.0.0.1:5432/xui?sslmode=disable

ترحيل تثبيت SQLite موجود إلى PostgreSQL

x-ui migrate-db --dsn "postgres://xui:password@127.0.0.1:5432/xui?sslmode=disable"
# ثم عيّن XUI_DB_TYPE و XUI_DB_DSN في /etc/default/x-ui وأعد التشغيل:
systemctl restart x-ui

يبقى ملف SQLite الأصلي دون تغيير؛ احذفه يدويًا بعد التحقق من الخلفية الجديدة.

Docker

يستمر الأمر الافتراضي docker compose up -d في استخدام SQLite. للتشغيل مع خدمة PostgreSQL المرفقة، أزِل التعليق عن سطري متغيرات البيئة XUI_DB_* في docker-compose.yml وشغّل باستخدام البروفايل:

docker compose --profile postgres up -d

تتضمن الصورة Fail2ban (مُفعَّل افتراضيًا) لفرض حدود IP لكل عميل. يحظر Fail2ban المخالفين باستخدام iptables، الذي يتطلب صلاحية NET_ADMIN. يمنح docker-compose.yml هذه الصلاحية مسبقًا عبر cap_add؛ إذا شغّلت الحاوية باستخدام docker run بدلاً من ذلك، فأضِف الصلاحيات بنفسك، وإلا فسيتم تسجيل عمليات الحظر دون تطبيقها أبدًا:

docker run -d --cap-add=NET_ADMIN --cap-add=NET_RAW ... ghcr.io/mhsanaei/3x-ui

متغيرات البيئة

المتغير	الوصف	الافتراضي
`XUI_DB_TYPE`	خلفية قاعدة البيانات: `sqlite` أو `postgres`	`sqlite`
`XUI_DB_DSN`	سلسلة اتصال PostgreSQL (عندما `XUI_DB_TYPE=postgres`)	—
`XUI_DB_FOLDER`	مجلد ملف قاعدة بيانات SQLite	`/etc/x-ui`
`XUI_DB_MAX_OPEN_CONNS`	الحد الأقصى للاتصالات المفتوحة (تجمّع PostgreSQL)	—
`XUI_DB_MAX_IDLE_CONNS`	الحد الأقصى للاتصالات الخاملة (تجمّع PostgreSQL)	—
`XUI_INIT_WEB_BASE_PATH`	مسار URI الأولي للوحة الويب	`/`
`XUI_ENABLE_FAIL2BAN`	تفعيل فرض حدود IP المعتمد على Fail2ban	`true`
`XUI_LOG_LEVEL`	مستوى السجل (`debug`، `info`، `warning`، `error`)	`info`
`XUI_DEBUG`	تفعيل وضع التصحيح	`false`
`XUI_TUNNEL_HEALTH_MONITOR`	تفعيل مراقب صحة النفق (يفحص عنوان URL ويعيد تشغيل xray بعد فشل متكرر؛ إعادة التشغيل تقطع جميع العملاء)	`false`
`XUI_TUNNEL_HEALTH_PROXY`	الوكيل الذي يُرسَل عبره الفحص؛ وجّهه إلى اتصال xray وارد محلي ليختبر الفحص النفق (مثل `socks5://127.0.0.1:1080`). القيمة الفارغة تعني أن الفحص يتحقق فقط من اتصال المضيف	—
`XUI_TUNNEL_HEALTH_URL`	عنوان URL الذي يُفحَص لمعرفة صحة النفق	`https://www.cloudflare.com/cdn-cgi/trace`
`XUI_TUNNEL_HEALTH_INTERVAL`	الفترة بين عمليات الفحص	`30s`
`XUI_TUNNEL_HEALTH_TIMEOUT`	مهلة كل عملية فحص	`10s`
`XUI_TUNNEL_HEALTH_FAILURES`	عدد حالات الفشل المتتالية قبل تشغيل إعادة التشغيل	`3`
`XUI_TUNNEL_HEALTH_COOLDOWN`	الحد الأدنى للتأخير بين عمليات إعادة التشغيل المتتالية	`5m`

اللغات المدعومة

تتوفر واجهة اللوحة بـ 13 لغة:

English · فارسی · العربية · 中文（简体） · 中文（繁體） · Español · Русский · Українська · Türkçe · Tiếng Việt · 日本語 · Bahasa Indonesia · Português (Brasil)

المساهمة

المساهمات مرحب بها. يرجى قراءة دليل المساهمة قبل فتح مشكلة (issue) أو طلب سحب (pull request).

شكر خاص إلى

alireza0

الاعتراف

Iran v2ray rules (الترخيص: GPL-3.0): قواعد توجيه v2ray/xray و v2ray/xray-clients المحسنة مع النطاقات الإيرانية المدمجة وتركيز على الأمان وحظر الإعلانات.
Russia v2ray rules (الترخيص: GPL-3.0): يحتوي هذا المستودع على قواعد توجيه V2Ray محدثة تلقائيًا بناءً على بيانات النطاقات والعناوين المحظورة في روسيا.

أدوات المجتمع

أدوات وتكاملات بناها المجتمع حول 3x-ui.

terraform-provider-3x-ui (الترخيص: MIT): إدارة الاتصالات الواردة والعملاء وإعدادات اللوحة وتكوين Xray كرمز باستخدام Terraform / OpenTofu.

دعم المشروع

إذا كان هذا المشروع مفيدًا لك، فقد ترغب في إعطائه🌟

13 KiB Raw Blame History