umputun/reproxyخادم HTTP(S) طرفي خفيف الوزن ووكيل عكسي مع SSL تلقائي، اكتشاف Docker/Consul، مصادقة لكل مسار، تحديد معدل الطلبات، وتحويل الفشل القائم على فحص الصحة.
<div align="center">
<img class="logo" src="https://raw.githubusercontent.com/umputun/reproxy/master/site/logo-bg.svg" width="355px" height="142px" alt="Reproxy | Simple Reverse Proxy"/>
</div>
Reproxy هو خادم HTTP(s) طرفي بسيط / وكيل عكسي يدعم مزوّدين متنوعين (docker، static، file، consul catalog). يقوم مزوّد واحد أو أكثر بتوفير معلومات حول الخادم المطلوب، وعنوان URL المطلوب، وعنوان URL الوجهة، وعنوان URL لفحص الحالة. يُوزَّع كملف ثنائي واحد أو كحاوية docker.
- إنهاء SSL تلقائي باستخدام <a href="https://letsencrypt.org/" rel="nofollow noopener noreferrer" target="_blank">Let's Encrypt</a>
- دعم شهادات SSL المقدَّمة من المستخدم
- قواعد وكيل بسيطة لكن مرنة
- مزوّد قواعد وكيل ثابت عبر سطر الأوامر
- مزوّد قواعد وكيل ديناميكي قائم على الملفات
- مزوّد Docker مع اكتشاف تلقائي
- مزوّد Consul Catalog مع الاكتشاف عبر وسوم الخدمة
- دعم عدة مضيفات (افتراضية)
- ضغط اختياري لحركة المرور
- تحكم اختياري في الوصول قائم على IP
- مصادقة أساسية لكل مسار
- حدود حجم ومهلات زمنية يحددها المستخدم
- توزيع كملف ثنائي واحد
- توزيع كحاوية Docker
- خادم أصول ثابتة مدمج مع وضع اختياري "متوافق مع SPA"
- دعم قواعد إعادة التوجيه
- محدِّد اختياري للنشاط الإجمالي وكذلك لنشاط المستخدم
- فحص حالة مباشر وتجاوز الفشل/موازنة الحمل
- خادم إدارة مع معلومات المسارات ومقاييس prometheus
- دعم الإضافات عبر RPC لتنفيذ وظائف مخصصة
- تسجيل اختياري بصيغة Apache Log Format وتقارير stdout مبسطة.
---
<div align="center">
[](https://github.com/umputun/reproxy/actions/workflows/ci.yml) [](https://coveralls.io/github/umputun/reproxy?branch=master) [](https://goreportcard.com/report/github.com/umputun/reproxy) [](https://hub.docker.com/r/umputun/reproxy)
</div>
يمكن تعيين الخادم (المضيف) كـ FQDN، أي `s.example.com`، أو `*` (يلتقط الكل) أو كتعبير نمطي (regex). المطابقة التامة لها الأولوية، لذا إذا وُجدت قاعدتان بخادمين `example.com` و`example\.(com|org)`، فإن الطلب إلى `example.com/some/url` سيطابق الأولى. يمكن أن يكون عنوان URL المطلوب تعبيرًا نمطيًا، على سبيل المثال `^/api/(.*)`، ويمكن أن يحتوي عنوان URL الوجهة على مجموعات مطابقة للتعبير النمطي، أي `http://d.example.com:8080/$1`. في المثال أعلاه، سيُوكَّل `http://s.example.com/api/something?foo=bar` إلى `http://d.example.com:8080/something?foo=bar`.
للراحة، تُوسَّع الطلبات التي تنتهي بـ `/` وبدون مجموعات regex إلى `/(.*)`، وتُوسَّع الوجهات في تلك الحالات إلى `/$1`. أي أن `/api/` -> `http://127.0.0.1/service` ستُترجم إلى `^/api/(.*)` -> `http://127.0.0.1/service/$1`.
يُدعم استبدال المضيف في عنوان URL الوجهة. على سبيل المثال، سيُستبدل `/files/${host}` باسم المضيف المطابق. يمكن أيضًا استخدام `$host` (بدون الأقواس المعقوفة).
يُدعم كل من HTTP وHTTPS. بالنسبة لـ HTTPS، يمكن استخدام شهادة ثابتة وكذلك شهادات ACME الآلية (Let's Encrypt). يمكن استخدام خادم أصول اختياري لتقديم الملفات الثابتة. يتطلب تشغيل reproxy تعريف مزوّد واحد على الأقل. بقية المعاملات اختيارية تمامًا ولها قيم افتراضية معقولة.
أمثلة:
- مع مزوّد ثابت: `reproxy --static.enabled --static.rule="*,example.com/api/(.*),https://api.example.com/$1"`
- مع اكتشاف تلقائي عبر docker: `reproxy --docker.enabled --docker.auto`
- كحاوية docker: `docker up -p 80:8080 umputun/reproxy --docker.enabled --docker.auto`
- مع SSL تلقائي: `docker up -p 80:8080 -p 443:8443 umputun/reproxy --docker.enabled --docker.auto --ssl.type=auto --ssl.fqdn=example.com`
## التثبيت
يتم توزيع Reproxy كملف ثنائي صغير مكتفٍ ذاتيًا بالإضافة إلى صورة docker. يدعم كل من الملف الثنائي والصورة معماريات متعددة وأنظمة تشغيل متعددة، بما في ذلك linux_x86_64 وlinux_arm64 وlinux_arm وmacos_x86_64 وmacos_arm64 وwindows_x86_64 وwindows_arm. كما نوفر حزم deb وrpm لكل من arm64 وx86.
- للحصول على توزيع ثنائي، نزّل الملف المناسب من [قسم الإصدارات](https://github.com/umputun/reproxy/releases)
- لمستخدمي Homebrew: `brew install umputun/apps/reproxy`
- حاوية docker متاحة على [Docker Hub](https://hub.docker.com/r/umputun/reproxy) وكذلك على [Github Container Registry](https://github.com/users/umputun/packages/container/reproxy/versions). أي `docker pull umputun/reproxy` أو `docker pull ghcr.io/umputun/reproxy`.
أحدث إصدار مستقر يحمل وسم docker `:vX.Y.Z` (مع الاسم البديل `:latest`) والفرع الرئيسي الحالي يحمل وسم `:master`.
## المزوّدون
قواعد الوكيل (proxy) تُوفَّر بواسطة مزوّدين متنوعين. المضمّن حاليًا - `file` و`docker` و`static` و`consul-catalog`. يمكن لكل مزوّد تعريف قواعد توجيه متعددة لكل من الطلبات الممرَّرة عبر الوكيل والملفات الثابتة (assets). يمكن للمستخدم تعيين عدة مزوّدين في الوقت نفسه.
_اطّلع على أمثلة لمزوّدين متنوعين في [examples](https://github.com/umputun/reproxy/tree/master/examples)_
### المزوّد الثابت (Static)
هذا أبسط مزوّد، إذ يعرّف جميع قواعد التعيين مباشرةً في سطر الأوامر (أو البيئة). تدعم قواعد متعددة. كل قاعدة تتكون من 3 إلى 7 عناصر مفصولة بفواصل `server,sourceurl,destination[,ping-url[,forward-health-checks[,timeout[,throttle]]]]`. على سبيل المثال:
- `*,^/api/(.*),https://api.example.com/$1` - تمرير جميع الطلبات إلى أي مضيف/خادم ببادئة `/api` إلى `https://api.example.com`
- `example.com,/foo/bar,https://api.example.com/zzz,https://api.example.com/ping` - تمرير جميع الطلبات إلى `example.com` ومع مسار `/foo/bar` إلى `https://api.example.com/zzz` ويستخدم `https://api.example.com/ping` لفحص الحالة.
- `example.com,/foo/bar,https://api.example.com/zzz,https://api.example.com/ping,true` - كما سبق ولكن يمرّر أيضًا طلبات `/ping` و`/health` إلى الخادم الخلفي.
- `example.com,^/upload/(.*),https://api.example.com/$1,,,5m` - مهلة طلب لكل مسار مدتها 5 دقائق (تُركت الحقول الرابع والخامس فارغة لتخطي ping-url وforward-health-checks).
- `example.com,^/login,https://api.example.com/login,,,,2` - حدّ معدّل (throttle) لكل مسار بمقدار 2 طلب/ثانية لكل مستخدم (تُركت الحقول الموضعية السابقة فارغة).
يحدد العنصر الرابع رابط ping اختياريًا يُستخدم للإبلاغ عن الحالة. ويُمكّن العنصر الخامس اختياريًا تمرير طلبات فحص الحالة إلى الخادم الخلفي (`true`، `yes`، `1`). راجع قسم [فحص الحالة](#ping-and-health-checks) لمزيد من التفاصيل. العنصر السادس هو مهلة طلب اختيارية لكل مسار (مدة Go، مثل `5m`، `30s`)؛ القيمة `0` أو الفارغ يرث إعداد `--timeout.write` العام. العنصر السابع هو حدّ اختياري لعدد الطلبات في الثانية لكل مستخدم لكل مسار؛ القيمة `0` أو الفارغ يرث `--throttle.user`. الحقول الموضعية الفارغة مسموح بها (مثل `,,` للحقول الوسطى غير المستخدمة).
### مزوّد الملف (File)
يستخدم هذا المزوّد ملف yaml يحتوي على قواعد التوجيه.
`reproxy --file.enabled --file.name=config.yml`
مثال على `config.yml`:
```yaml
default: # the same as * (catch-all) server
- { route: "^/api/svc1/(.*)", dest: "http://127.0.0.1:8080/blah1/$1" }
- {
route: "/api/svc3/xyz",
dest: "http://127.0.0.3:8080/blah3/xyz",
ping: "http://127.0.0.3:8080/ping",
remote: "192.168.1.0/24, 127.0.0.1", # optional, restrict access to the route
forward-health-checks: true # optional, forward /ping and /health to backend
}
- {
route: "^/admin/(.*)",
dest: "http://127.0.0.4:8080/$1",
auth: "admin:$2y$05$..." # optional, per-route basic auth (htpasswd bcrypt format)
}
- {
route: "^/upload/(.*)",
dest: "http://127.0.0.5:8080/$1",
timeout: 5m # optional, per-route request timeout (Go duration). 0 or omitted inherits --timeout.write
}
- {
route: "^/login",
dest: "http://127.0.0.6:8080/login",
throttle: 2 # optional, per-route req/sec per user. 0 or omitted inherits --throttle.user
}
srv.example.com:
- { route: "^/api/svc2/(.*)", dest: "http://127.0.0.2:8080/blah2/$1/abc" }
- { route: "/web/", dest: "/var/www", "assets": true }
"*.files.example.com":
- { route: "^/files/(.*)", dest: "http://123.123.200.200:8080/$host/$1" }
```
هذا مزوّد ديناميكي وسيتم تطبيق تغيير الملف تلقائيًا.
**يمكن تقديم عدة مواقع ثابتة على نطاقات مختلفة** باستخدام أسماء الخوادم كمفاتيح مع `assets: true`:
```yaml
site-en.example.com:
- { route: "/", dest: "/var/www/en", "assets": true }
site-ru.example.com:
- { route: "/", dest: "/var/www/ru", "assets": true }
```
**مهم:** يجب أن يكون حقل `route` لقواعد الأصول بادئة مسار (مثل `/`، `/web/`)، وليس تعبيرًا نمطيًا (regex). أنماط التعبيرات النمطية مثل `^/(.*)` لن تعمل مع `assets: true` لأن مطابقة الأصول الثابتة تستخدم مقارنة بادئة المسار، وليس التعبيرات النمطية.
### مزوّد Docker
يدعم مزوّد Docker اكتشافًا تلقائيًا بالكامل (مع `--docker.auto`) دون الحاجة إلى أي إعداد إضافي. افتراضيًا، يعيد توجيه جميع الطلبات مثل `http://<url>/<container name>/(.*)` إلى عنوان IP الداخلي للحاوية المحددة والمنفذ المكشوف. سيتم اكتشاف الحاويات النشطة (قيد التشغيل) فقط.
يمكن تغيير هذا الافتراضي باستخدام التسميات (labels):
- `reproxy.server` - الخادم (اسم المضيف) المراد مطابقته. يمكن أن يكون أيضًا قائمة من الخوادم مفصولة بفواصل.
- `reproxy.route` - المسار المصدر (الموقع)
- `reproxy.dest` - مسار الوجهة. ملاحظة: هذا ليس عنوان URL كاملًا، بل مجرد المسار الذي سيُضاف إلى ip:port الخاص بالحاوية
- `reproxy.port` - منفذ الوجهة للحاوية المكتشفة
- `reproxy.ping` - مسار ping لحاوية الوجهة.
- `reproxy.remote` - تقييد الوصول إلى المسار بقائمة من الشبكات الفرعية أو عناوين IP مفصولة بفواصل
- `reproxy.auth` - طلب المصادقة الأساسية (basic auth) للمسار بأزواج `user:bcrypt_hash` مفصولة بفواصل (تُنشأ بواسطة `htpasswd -nbB`)
- `reproxy.assets` - تعيين الأصول كـ `web-root:location`، على سبيل المثال `reproxy.assets=/web:/var/www`
- `reproxy.keep-host` - الإبقاء على ترويسة المضيف كما هي (`yes`، `true`، `1`) أو استبدالها بمضيف الوجهة (`no`، `false`، `0`)
- `reproxy.forward-health-checks` - إعادة توجيه طلبات `/ping` و`/health` إلى الخادم الخلفي بدلًا من معالجتها بواسطة reproxy (`yes`، `true`، `1`). مفيد عندما يكون للخادم الخلفي نقاط نهاية فحص صحة خاصة به مع استجابات خاصة بالتطبيق.
- `reproxy.timeout` - مهلة الطلب لكل مسار كمدة Go (مثل `5m`، `30s`). القيمة `0` أو عدم التعيين ترث `--timeout.write` العام. يتم تجاهل القيم غير الصالحة مع تحذير.
- `reproxy.throttle` - حد الطلبات/ثانية لكل مستخدم لكل مسار. القيمة `0` أو عدم التعيين ترث `--throttle.user`. يتم تجاهل القيم غير الصالحة أو السالبة مع تحذير.
- `reproxy.enabled` - تمكين (`yes`، `true`، `1`) أو تعطيل (`no`، `false`، `0`) الحاوية من وجهات reproxy.
يرجى ملاحظة: بدون `--docker.auto`، يجب أن تحتوي حاوية الوجهة على واحدة على الأقل من تسميات `reproxy.*` لتُعتبر وجهة محتملة.
مع `--docker.auto`، ستُعتبر جميع الحاويات ذات المنفذ المكشوف وجهات توجيه. هناك 3 طرق لتقييد ذلك:
- استبعاد بعض الحاويات صراحةً باستخدام `--docker.exclude`، أي `--docker.exclude=c1 --docker.exclude=c2 ...`
- السماح بشبكة Docker معينة فقط باستخدام `--docker.network`
- تعيين التسمية `reproxy.enabled=false` أو `reproxy.enabled=no` أو `reproxy.enabled=0`
إذا لم يتم تعريف `reproxy.route`، فإن المسار الافتراضي هو `^/<container_name>/(.*)`. في حال كان يجب أن يكون لجميع المصادر المُوجَّهة نفس نمط البادئة، على سبيل المثال `/api/(.*)`، يمكن للمستخدم تعريف البادئة المشتركة (في هذه الحالة `/api`) لجميع المسارات القائمة على الحاويات. يمكن القيام بذلك باستخدام المعامل `--docker.prefix`.
يتيح مزوّد Docker أيضًا تعريف مجموعات متعددة من تسميات `reproxy.N.something` لمطابقة مسارات متعددة ومختلفة على نفس الحاوية. هذا مفيد لأنه في بعض الحالات قد تكشف حاوية واحدة عن نقاط نهاية متعددة، على سبيل المثال واجهة برمجة تطبيقات عامة وواجهة برمجة تطبيقات إدارية. يمكن استخدام جميع التسميات أعلاه مع "N-index"، أي `reproxy.1.server`، `reproxy.1.port` وهكذا. يجب أن يكون N في النطاق من 0 إلى 9.
هذا مزوّد ديناميكي وسيتم تطبيق أي تغيير في حالة الحاوية تلقائيًا.
### مزوّد Consul Catalog
الاستخدام: `reproxy --consul-catalog.enabled`
يستدعي مزوّد Consul Catalog واجهة Consul API بشكل دوري (كل ثانية افتراضيًا) للحصول على الخدمات التي تحتوي على أي وسم (tag) ببادئة `reproxy.`. يمكن للمستخدم إعادة تعريف فاصل الفحص باستخدام علامة سطر الأوامر `--consul-catalog.interval` وكذلك عنوان consul باستخدام خيار سطر الأوامر `--consul-catalog.address`. العنوان الافتراضي هو `http://127.0.0.1:8500`.
على سبيل المثال:
```
reproxy --consul-catalog.enabled --consul-catalog.address=http://192.168.1.100:8500 --consul-catalog.interval=10s
```
بشكل افتراضي، يضبط المزوّد القيم لكل خدمة:
- enabled `false`
- server `*`
- route `^/(.*)`
- dest `http://<SERVICE_ADDRESS_FROM_CONSUL>/$1`
- ping `http://<SERVICE_ADDRESS_FROM_CONSUL>/ping`
يمكن تغيير هذه القيم الافتراضية باستخدام الوسوم:
- `reproxy.server` - الخادم (اسم المضيف) المطلوب مطابقته. يمكن أيضاً أن يكون قائمة من الخوادم مفصولة بفواصل.
- `reproxy.route` - المسار المصدر (الموقع)
- `reproxy.dest` - مسار الوجهة. ملاحظة: هذا ليس عنوان URL كاملاً، بل مجرد المسار الذي سيُضاف إلى ip:port الخاص بالخدمة
- `reproxy.port` - منفذ الوجهة للخدمة المكتشفة
- `reproxy.remote` - تقييد الوصول إلى المسار بقائمة من الشبكات الفرعية أو عناوين IP مفصولة بفواصل
- `reproxy.auth` - طلب المصادقة الأساسية للمسار بأزواج `user:bcrypt_hash` مفصولة بفواصل (تُنشأ بواسطة `htpasswd -nbB`)
- `reproxy.ping` - مسار ping لخدمة الوجهة.
- `reproxy.forward-health-checks` - تمرير طلبات `/ping` و `/health` إلى الخادم الخلفي (`true`، `yes`، `1`).
- `reproxy.timeout` - مهلة الطلب لكل مسار كمدة Go (مثل `5m`، `30s`). القيمة `0` أو عدم التعيين ترث `--timeout.write` العام. يتم تجاهل القيم غير الصالحة مع تحذير.
- `reproxy.throttle` - حد الطلبات/ثانية لكل مستخدم لكل مسار. القيمة `0` أو عدم التعيين ترث `--throttle.user`. يتم تجاهل القيم غير الصالحة أو السالبة مع تحذير.
- `reproxy.enabled` - تفعيل (`yes`، `true`، `1`) أو تعطيل (`أي قيمة مختلفة`) الخدمة من وجهات reproxy.
### تفاصيل خاصة بـ Compose
في حال تم تعيين القواعد كجزء من بيئة docker compose، فإن الوجهة التي تحتوي على مجموعة regex ستتعارض مع صيغة compose. أي أن محاولة استخدام `https://api.example.com/$1` في بيئة compose ستفشل بسبب خطأ في الصيغة. الحل القياسي هنا هو "تهريب" علامة `$` باستبدالها بـ `$$`، أي `https://api.example.com/$$1`. هذا الاستبدال مدعوم من docker compose وليس له علاقة بـ reproxy نفسه. طريقة أخرى هي استخدام `@` بدلاً من `$` وهو مدعوم على مستوى reproxy، أي `https://api.example.com/@1`_
## دعم SSL
يمكن ضبط وضع SSL (بشكل افتراضي لا شيء) على `auto` (شهادات ACME/LE)، أو `static` (شهادة موجودة) أو `none`. إذا تم تفعيل `auto` فسيتم إصدار شهادة SSL تلقائياً لجميع أسماء الخوادم المكتشفة. يمكن للمستخدم تجاوز ذلك بتعيين قيمة (قيم) `--ssl.fqdn`. في وضعي SSL `auto` و `static`، سيضيف Reproxy تلقائياً ترويسات `X-Forwarded-Proto` و `X-Forwarded-Port`. هذه الترويسات مفيدة للخدمات الموجودة خلف الوكيل لمعرفة البروتوكول الأصلي (http أو https) ورقم المنفذ المستخدم من قبل العميل.
عند استخدام ACME مع مزوّدي الاكتشاف (docker، file، consul)، يتم الحصول على شهادات SSL تلقائياً للخوادم المكتشفة حديثاً دون الحاجة إلى إعادة تشغيل reproxy.
### تحديات ACME
يدعم Reproxy نوعين من تحديات ACME للتحقق من شهادة SSL:
1. **تحدي HTTP-01** (افتراضي): يتحقق من ملكية النطاق عبر تقديم رمز على عنوان URL محدد بـ HTTP. يتطلب أن يكون المنفذ 80 متاحاً للعموم.
2. **تحدي DNS-01**: يتحقق من ملكية النطاق عبر إنشاء سجلات DNS TXT. هذه الطريقة:
- لا تتطلب أن يكون المنفذ 80 متاحاً
- تعمل مع الشهادات الشاملة (wildcard)
- تتطلب إعداد مزوّد DNS مدعوم
#### اختيار التحدي
يحدد Reproxy تلقائياً طريقة التحدي التي سيستخدمها بناءً على إعداداتك:
- **HTTP-01** (افتراضي): يُستخدم عند عدم إعداد مزوّد DNS
- **DNS-01**: يُستخدم عند إعداد مزوّد DNS
لا تحتاج إلى اختيار نوع التحدي صراحةً - فقط قم بإعداد مزوّد DNS إذا كنت تريد استخدام تحديات DNS-01.
تنتهي مهلة فحوصات انتشار DNS بعد دقيقتين افتراضياً. زد هذه المدة باستخدام `--ssl.dns.propagation-timeout=5m` للنطاقات التي تنشر سجلات التحدي ببطء. يتحكم الخيار `--ssl.dns.ttl` في TTL للسجل ولا يغيّر مهلة الانتشار.
#### مزوّدو DNS المدعومون حالياً
يتضمن Reproxy حالياً دعماً لمزوّدي DNS التاليين:
- **Cloudflare**: `--ssl.dns.type=cloudflare --ssl.dns.cloudflare.api-token=TOKEN`
- **Route53 (AWS)**: `--ssl.dns.type=route53 --ssl.dns.route53.region=REGION --ssl.dns.route53.hosted-zone-id=ID`
- **Gandi**: `--ssl.dns.type=gandi --ssl.dns.gandi.bearer-token=TOKEN`
- **DigitalOcean**: `--ssl.dns.type=digitalocean --ssl.dns.digitalocean.api-token=TOKEN`
- **Hetzner**: `--ssl.dns.type=hetzner --ssl.dns.hetzner.api-token=TOKEN`
- **Linode**: `--ssl.dns.type=linode --ssl.dns.linode.api-token=TOKEN`
- **GoDaddy**: `--ssl.dns.type=godaddy --ssl.dns.godaddy.api-token=TOKEN`
- **Namecheap**: `--ssl.dns.type=namecheap --ssl.dns.namecheap.api-key=KEY --ssl.dns.namecheap.user=USER`
- **Scaleway**: `--ssl.dns.type=scaleway --ssl.dns.scaleway.secret-key=KEY --ssl.dns.scaleway.organization-id=ID`
- **Porkbun**: `--ssl.dns.type=porkbun --ssl.dns.porkbun.api-key=KEY --ssl.dns.porkbun.api-secret-key=SECRET`
- **DNSimple**: `--ssl.dns.type=dnsimple --ssl.dns.dnsimple.api-access-token=TOKEN --ssl.dns.dnsimple.account-id=ID`
- **DuckDNS**: `--ssl.dns.type=duckdns --ssl.dns.duckdns.api-token=TOKEN`
مثال باستخدام Cloudflare كمزوّد DNS:
```
export CLOUDFLARE_API_TOKEN=your_api_token
reproxy --ssl.type=auto [email protected] --ssl.fqdn=example.com
```
تحدي DNS-01 مفيد بشكل خاص عندما:
- لا يكون المنفذ 80 مكشوفًا للعامة على خادمك
- تحتاج إلى شهادات wildcard (مثل `*.example.com`)
- تكون خلف جدران حماية مقيّدة
## الترويسات (Headers)
يتيح Reproxy تنقية (إزالة) الترويسات الواردة عبر تمرير المعامل `--drop-header` (يمكن تكراره). قد يكون هذا المعامل مفيدًا للتأكد من أن بعض الترويسات، التي تُضبط داخليًا بواسطة الخدمات، لا يمكن للمستخدم النهائي ضبطها أو تزويرها. على سبيل المثال، إذا كانت بعض الخدمات المسؤولة عن المصادقة تضبط `X-Auth-User` و`X-Auth-Token`، فمن المنطقي على الأرجح إسقاط هذه الترويسات من الطلبات الواردة عبر تمرير المعامل `--drop-header=X-Auth-User --drop-header=X-Auth-Token` أو عبر متغير البيئة `DROP_HEADERS=X-Auth-User,X-Auth-Token`
الوظيفة المعاكسة، أي ضبط الترويسة (الترويسات) الصادرة، مدعومة أيضًا. يمكن أن تكون مفيدة في حالات كثيرة، على سبيل المثال فرض بعض قواعد CORS المخصصة، والترويسات المتعلقة بالأمان، وما إلى ذلك. يمكن القيام بذلك عبر المعامل `--header` (يمكن تكراره) أو متغير البيئة `HEADER`. على سبيل المثال، هذه هي الطريقة التي يمكن بها القيام بذلك باستخدام docker compose:
```yaml
environment:
- HEADER=
X-Frame-Options:SAMEORIGIN,
X-XSS-Protection:1; mode=block;,
Content-Security-Policy:default-src 'self'; style-src 'self' 'unsafe-inline';
```
## التسجيل
بشكل افتراضي لا يتم إنشاء سجل طلبات. يمكن تفعيل ذلك عن طريق تعيين `--logger.enabled`. يحتوي السجل (الذي يتم تدويره تلقائيًا) على [Apache Combined Log Format](http://httpd.apache.org/docs/2.2/logs.html#combined)
يمكن للمستخدم أيضًا تفعيل سجل stdout باستخدام `--logger.stdout`. لن يؤثر ذلك على تسجيل الملفات المذكور أعلاه، لكنه سيعرض بعض المعلومات البسيطة حول الطلبات المعالجة، شيء مثل هذا:
```
2021/04/16 01:17:25.601 [INFO] GET - /echo/image.png - xxx.xxx.xxx.xxx - 200 (155400) - 371.661251ms
2021/04/16 01:18:18.959 [INFO] GET - /api/v1/params - xxx.xxx.xxx.xxx - 200 (74) - 1.217669m
```
## خادم الأصول
يمكن للمستخدمين تشغيل خادم الأصول (معطّل افتراضيًا) لخدمة الملفات الثابتة. طالما تم تعيين `--assets.location`، فإنه يعامل كل طلب غير موجه عبر وكيل تحت `assets.root` كطلب لملفات ثابتة. يمكن استخدام خادم الأصول دون أي مزوّدي وكيل؛ في هذا الوضع، يعمل reproxy كخادم ويب بسيط للمحتوى الثابت. يدعم خادم الأصول أيضًا "وضع spa" مع `--assets.spa` حيث تُوجَّه جميع الطلبات غير الموجودة إلى `index.html`.
بالإضافة إلى خادم الأصول الشائع، تُدعَم خوادم أصول مخصصة متعددة. لكل مزوّد طريقة مختلفة لتعريف هذه القاعدة الثابتة، وقد لا يدعمها بعض المزوّدين على الإطلاق. على سبيل المثال، تكون خوادم الأصول المتعددة منطقية في المزوّد الثابت (مزوّد سطر الأوامر)، ومزوّد الملفات، وحتى مفيدة مع مزوّدي docker، لكنها لا تكون منطقية تقريبًا مع مزوّد كتالوج consul.
1. المزوّد الثابت - إذا كان عنصر المصدر مسبوقًا بـ `assets:` أو `spa:` فسيُعامَل كخادم ملفات. على سبيل المثال `*,assets:/web,/var/www,` سيخدم جميع طلبات `/web/*` بخادم ملفات فوق دليل `/var/www`.
2. مزوّد الملفات - تعيين الحقول الاختيارية `assets: true` أو `spa: true`. ملاحظة: يجب أن يكون حقل `route` بادئة مسار (مثل `/`، `/web/`)، وليس نمط regex.
3. مزوّد docker - `reproxy.assets=web-root:location`، أي `reproxy.assets=/web:/var/www`. يتم التبديل إلى وضع spa بتعيين `reproxy.spa` إلى `yes` أو `true`
### التخزين المؤقت
يدعم خادم الأصول التحكم في التخزين المؤقت عبر المعامل `--assets.cache=<duration>`. مدة `0s` (الافتراضية) تُلغي التحكم في التخزين المؤقت. المدة هي سلسلة من الأرقام العشرية، كل منها بكسر اختياري ولاحقة وحدة، مثل "300ms" أو "1.5h" أو "2h45m". وحدات الوقت الصالحة هي "ns" و"us" (أو "µs") و"ms" و"s" و"m" و"h" و"d".
هناك طريقتان لتعيين مدة التخزين المؤقت:
1. قيمة واحدة لجميع الأصول الثابتة. هذا بسيط مثل `--assets.cache=48h`.
2. مدة مخصصة لأنواع mime مختلفة. يجب أن تتضمن جزأين - القيمة الافتراضية وأزواج mime:duration. في سطر الأوامر يبدو هذا كخيارات `--assets.cache` متعددة، أي `--assets.cache=48h --assets.cache=text/html:24h --assets.cache=image/png:2h`. يجب أن تكون قيم البيئة مفصولة بفواصل، أي `ASSETS_CACHE=48h,text/html:24h,image/png:2h`
يمكن تعيين صفحة 404 مخصصة (غير موجود) عبر المعامل `--assets.not-found=<path>`. يجب أن يكون المسار نسبيًا إلى جذر الأصول.
## استخدام reproxy كصورة أساسية
خدمة المحتوى الثابت البحت هي أحد حالات الاستخدام الشائعة. عادةً يُستخدم هذا لحاوية الواجهة الأمامية المنفصلة التي توفر واجهة المستخدم فقط. مع خادم الأصول، يصبح إنشاء مثل هذه الحاوية أمرًا تافهًا تقريبًا. هذا مثال من الحاوية التي تخدم [reproxy.io](http://reproxy.io)
```docker
FROM node:22-alpine as build
WORKDIR /build
COPY site/ /build
COPY README.md /build/src/index.md
RUN yarn --frozen-lockfile
RUN yarn build
RUN ls -la /build/public
FROM ghcr.io/umputun/reproxy
COPY --from=build /build/public /srv/site
EXPOSE 8080
USER app
ENTRYPOINT ["/srv/reproxy", "--assets.location=/srv/site"]
```
كل ما يحتاجه هو نسخ الأصول الثابتة إلى موقع ما وتمرير هذا الموقع كـ `"--assets.location` إلى نقطة دخول reproxy.
## الوضع الملائم لتطبيقات SPA
تعتمد بعض تطبيقات SPA على الوكيل (proxy) للتعامل مع خطأ 404 على الأصول الثابتة بطريقة خاصة، عبر إعادة توجيهه إلى "/index.html". هذا مشابه لتوجيه `try_files $uri $uri/ …` في nginx، ويبدو أن هذه الوظيفة مهمة إلى حد ما لتطبيقات الويب الحديثة.
هذا الوضع معطّل افتراضيًا ويمكن تفعيله عبر تعيين `--assets.spa` أو متغير البيئة `ASSETS_SPA=true`.
## إعادة التوجيه
افتراضيًا يعامل reproxy الوجهة كموقع وكيل، أي أنه يستدعي طلب http داخليًا ويعيد الاستجابة إلى العميل. ومع ذلك، عبر إضافة البادئة `@code` إلى عنوان url الوجهة يمكن تغيير هذا السلوك إلى إعادة توجيه دائم (رمز الحالة 301) أو مؤقت (رمز الحالة 302). أي أن تعيين الوجهة إلى `@301 https://example.com/something` سيؤدي إلى إعادة توجيه http دائم إلى `Location: https://example.com/something`
الرموز المدعومة:
- `@301`، `@perm` - إعادة توجيه دائم
- `@302`، `@temp`، `@tmp` - إعادة توجيه مؤقت
## خيارات إضافية
- `--gzip` يفعّل ضغط gzip (أو deflate) للاستجابات. يُتخذ القرار لكل استجابة على حدة، بناءً على ترويساتها النهائية:
---
[Read more](https://github.com/umputun/reproxy)