umputun/reproxyخادم HTTP(S) طرفي خفيف الوزن ووكيل عكسي مع SSL تلقائي، اكتشاف Docker/Consul، مصادقة لكل مسار، تحديد معدل الطلبات، وتحويل الفشل القائم على فحص الصحة.
"? No, it ends with "Example of config.yml:" and then the line ends. That is the end of the chunk. So we translate that.
We must ensure no extra text is added.
Let's produce the translation.
Reproxy هو خادم حافة HTTP(s) بسيط / وكيل عكسي يدعم مزودين متعددين (docker، static، file، consul catalog). يقوم مزود واحد أو أكثر بتوفير معلومات عن الخادم المطلوب، وعنوان URL المطلوب، وعنوان URL الوجهة، وعنوان URL فحص الصحة. يتم توزيعه كملف ثنائي واحد أو كحاوية docker.
يمكن تعيين الخادم (المضيف) كـ FQDN، على سبيل المثال s.example.com، أو * (ملتقط الكل) أو تعبير عادي. المطابقة التامة لها الأولوية، فإذا كانت هناك قاعدتان بخادمين 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.
لتسهيل الاستخدام، الطلبات التي تنتهي بـ / وبدون مجموعات تعبير عادي تُوسع إلى /(.*)، والوجهات في تلك الحالات تُوسع إلى /$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"reproxy --docker.enabled --docker.autodocker up -p 80:8080 umputun/reproxy --docker.enabled --docker.autodocker 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.
brew install umputun/apps/reproxydocker pull umputun/reproxy أو docker pull ghcr.io/umputun/reproxy.الإصدار المستقر الأحدث يحمل علامة docker :vX.Y.Z (مع اسم مستعار :latest) والمستودع الحالي يحمل علامة :master.
يتم توفير قواعد الوكيل بواسطة مزودين مختلفين. المزودون المضمنون حالياً - file، docker، static و consul-catalog. يمكن لكل مزود تعريف قواعد توجيه متعددة لكل من الطلب الموكَل والثابت (الأصول). يمكن للمستخدم تعيين مزودين متعددين في نفس الوقت.
راجع أمثلة على مزودين مختلفين في الأمثلة
هذا هو أبسط مزود يحدد جميع قواعد التعيين مباشرة في سطر الأوامر (أو البيئة). يتم دعم قواعد متعددة. كل قاعدة تتكون من 3 إلى 7 عناصر مفصولة بفواصل server,sourceurl,destination[,ping-url[,forward-health-checks[,timeout[,throttle]]]]. على سبيل المثال:
*,^/api/(.*),https://api.example.com/$1 - توجيه جميع الطلبات إلى أي مضيف/خادم ببادئة /api إلى https://api.example.comexample.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).العنصر الرابع يحدد عنوان ping اختياري يستخدم لتقرير الصحة. العنصر الخامس يمكّن اختياريًا تمرير طلبات فحص الصحة إلى الخلفية (true، yes، 1). راجع قسم فحص الصحة لمزيد من التفاصيل. العنصر السادس هو مهلة زمنية اختيارية لكل مسار (مدة Go، مثل 5m، 30s)؛ 0 أو فارغ يرث الإعداد العام --timeout.write. العنصر السابع هو حد اختياري لعدد الطلبات/ثانية لكل مستخدم لكل مسار؛ 0 أو فارغ يرث --throttle.user. يُسمح بالحقول الموضعية الفارغة (مثل ,, للحقول الوسطى غير المستخدمة).
يستخدم هذا المزود ملف yaml مع قواعد التوجيه.
reproxy --file.enabled --file.name=config.yml
مثال لـ config.yml:```yaml
default: # the same as * (catch-all) server
هذا مزود ديناميكي وسيتم تطبيق تغيير الملف تلقائيًا.
يمكن تقديم **مواقع ثابتة متعددة على نطاقات مختلفة** عن طريق استخدام أسماء الخوادم كمفاتيح مع `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/)، وليس تعبيرًا منتظمًا. أنماط التعبير المنتظم مثل ^/(.*) لن تعمل مع assets: true لأن مطابقة الأصول الثابتة تستخدم مقارنة بادئة المسار، وليس التعبير المنتظم.
يدعم مزود Docker الاكتشاف التلقائي بالكامل (مع --docker.auto) دون الحاجة إلى تكوين إضافي. بشكل افتراضي، يعيد توجيه جميع الطلبات مثل http://<url>/<container name>/(.*) إلى عنوان IP الداخلي للحاوية المحددة والمنفذ المكشوف. سيتم اكتشاف الحاويات النشطة (قيد التشغيل) فقط.
يمكن تغيير هذا الإعداد الافتراضي باستخدام الوسوم:
reproxy.server - الخادم (اسم المضيف) للمطابقة. يمكن أيضًا أن يكون قائمة بخوادم مفصولة بفواصل.reproxy.route - المسار المصدر (الموقع)reproxy.dest - مسار الوجهة. ملاحظة: هذا ليس عنوان URL كاملاً، بل مجرد المسار الذي سيتم إلحاقه بـ ip:port للحاويةreproxy.port - منفذ الوجهة للحاوية المكتشفةreproxy.ping - مسار ping لحاوية الوجهة.reproxy.remote - تقييد الوصول إلى المسار بقائمة من الشبكات الفرعية أو عناوين IP مفصولة بفواصلreproxy.auth - طلب مصادقة أساسية للمسار بأزواج user:bcrypt_hash مفصولة بفواصل (يتم إنشاؤها بواسطة htpasswd -nbB)reproxy.assets - تعيين تعيين الأصول كـ web-root:location، على سبيل المثال reproxy.assets=/web:/var/wwwيرجى ملاحظة: بدون --docker.auto، يجب أن تحتوي حاوية الوجهة على واحد على الأقل من وسوم reproxy.* لاعتبارها وجهة محتملة.
مع --docker.auto، سيتم اعتبار جميع الحاويات ذات المنفذ المكشوف كوجهات توجيه. هناك 3 طرق لتقييد ذلك:
--docker.exclude، أي --docker.exclude=c1 --docker.exclude=c2 ...--docker.networkreproxy.enabled=false أو reproxy.enabled=no أو reproxy.enabled=0إذا لم يتم تعريف reproxy.route، فإن المسار الافتراضي هو ^/<container_name>/(.*). في حالة رغبة جميع المصادر الوكيلة في الحصول على نفس نمط البادئة، على سبيل المثال /api/(.*)، يمكن للمستخدم تعريف البادئة المشتركة (في هذه الحالة /api) لجميع المسارات القائمة على الحاوية. يمكن القيام بذلك باستخدام معلمة --docker.prefix.
يسمح مزود Docker أيضًا بتعريف مجموعات متعددة من وسوم reproxy.N.something لمطابقة مسارات متعددة ومتميزة على نفس الحاوية. هذا مفيد لأنه في بعض الحالات قد تعرض حاوية واحدة نقاط نهاية متعددة، على سبيل المثال، واجهة برمجة تطبيقات عامة وبعض واجهات برمجة التطبيقات الإدارية. يمكن استخدام جميع الوسوم أعلاه مع "مؤشر N"، أي reproxy.1.server، reproxy.1.port وهكذا. يجب أن يكون N في النطاق من 0 إلى 9.
هذا مزود ديناميكي وسيتم تطبيق أي تغيير في حالة الحاوية تلقائيًا.
الاستخدام: reproxy --consul-catalog.enabled
يقوم مزود Consul Catalog باستدعاء واجهة برمجة تطبيقات Consul بشكل دوري (كل ثانية افتراضيًا) للحصول على الخدمات التي تحتوي على أي وسم ببادئة 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
بشكل افتراضي، يقوم المزوّد بتعيين قيم لكل خدمة:
- مفعّل `false`
- خادم `*`
- مسار `^/(.*)`
- وجهة `http://<SERVICE_ADDRESS_FROM_CONSUL>/$1`
- اختبار اتصال `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` - مسار اختبار الاتصال لخدمة الوجهة.
- `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** (الافتراضي): يتحقق من ملكية النطاق عن طريق تقديم رمز مميز في عنوان HTTP محدد. يتطلب أن يكون المنفذ 80 متاحًا للعامة.
2. **تحدي DNS-01**: يتحقق من ملكية النطاق عن طريق إنشاء سجلات TXT في DNS. هذه الطريقة:
- لا تتطلب أن يكون المنفذ 80 متاحًا
- تعمل مع الشهادات الجامعة (wildcard)
- تتطلب تكوين مزوّد DNS مدعوم
#### اختيار التحدي
يحدد Reproxy تلقائيًا طريقة التحدي التي سيستخدمها بناءً على تكوينك:
- **HTTP-01** (الافتراضي): يُستخدم عند عدم تكوين مزوّد DNS
- **DNS-01**: يُستخدم عند تكوين مزوّد DNS
لا تحتاج إلى تحديد نوع التحدي صراحةً - فقط قم بتكوين مزوّد DNS إذا كنت ترغب في استخدام تحديات DNS-01.
#### مزوّدو 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 يكون مفيدًا بشكل خاص عندما:
يتيح 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 المشترك](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.
assets: أو spa: فسيتم التعامل معه كخادم ملفات. على سبيل المثال، *,assets:/web,/var/www, سيخدم جميع طلبات /web/* باستخدام خادم ملفات فوق دليل /var/www.assets: true أو spa: true. ملاحظة: يجب أن يكون حقل route بادئة مسار (مثل /، /web/)، وليس نمط تعبير منتظم.reproxy.assets=web-root:location، أي reproxy.assets=/web:/var/www. يتم التبديل إلى وضع SPA عن طريق تعيين reproxy.spa إلى yes أو يدعم خادم الأصول التحكم في التخزين المؤقت بواسطة المعامل --assets.cache=<duration>. المدة 0s (الافتراضية) تعطل التحكم في التخزين المؤقت. المدة هي سلسلة من الأرقام العشرية، كل منها مع كسر اختياري ولاحقة وحدة، مثل "300ms"، "1.5h" أو "2h45m". وحدات الوقت الصالحة هي "ns"، "us" (أو "µs")، "ms"، "s"، "m"، "h" و "d".
هناك طريقتان لتعيين مدة التخزين المؤقت:
--assets.cache=48h.--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.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 على الوكيل لمعالجة 404 على الأصول الثابتة بطريقة خاصة، عن طريق إعادة توجيهها إلى "/index.html". هذا مشابه لتوجيه nginx `try_files $uri $uri/ …` ومن الواضح أن هذه الوظيفة مهمة إلى حد ما لتطبيقات الويب الحديثة.
هذا الوضع معطل افتراضيًا ويمكن تفعيله عن طريق تعيين `--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 للاستجابات.
- `--max=N` يسمح بتعيين الحد الأقصى لحجم الطلب (الافتراضي 64 كيلوبايت). تعيينه إلى `0` يُعطّل فحص الحجم.
- `--timeout.*` مهلات زمنية متنوعة لكل من الخادم ونقل الوكيل. راجع قسم `timeout` في [جميع خيارات التطبيق](#all-application-options). القيمة صفر أو سالبة تعني عدم وجود مهلة زمنية.
- `--insecure` يُعطّل التحقق من SSL على المضيف الوجهة. هذا مفيد للشهادات ذاتية التوقيع.
## المنافذ الافتراضية
لإلغاء الحاجة إلى تمرير معلمات/بيئة مخصصة، فإن `--listen` الافتراضي ديناميكي ويحاول أن يكون معقولاً ومفيدًا للحالات النموذجية:
- إذا قام المستخدمون بتعيين أي شيء إلى `--listen`، يتم تجاهل جميع المنطق أدناه، ويتم استخدام host:port الذي تم تمريره مباشرة.
- إذا لم يقم المستخدمون بتعيين أي شيء إلى `--listen` وكان reproxy يعمل خارج حاوية docker، فإن الإعداد الافتراضي هو `127.0.0.1:80` لوضع http (`ssl.type=none`) و `127.0.0.1:443` لوضع ssl (`ssl.type=auto` أو `ssl.type=static`).
- إذا لم يقم المستخدمون بتعيين أي شيء إلى `--listen` وكان reproxy يعمل داخل docker، فإن الإعداد الافتراضي هو `0.0.0.0:8080` لوضع http، و `0.0.0.0:8443` لوضع ssl.
إعداد افتراضي آخر يتم تعيينه بطريقة ديناميكية مماثلة هو `--ssl.http-port`. للتشغيل داخل حاوية docker يتم تعيينه إلى `8080` وبدون ذلك إلى `80`.
## Ping، فحوصات الصحة وتجاوز الفشل
يوفر reproxy نقطتي نهاية لهذا الغرض:
- `/ping` يستجيب بـ `pong` ويشير إلى أن reproxy قيد التشغيل ويعمل
- `/health` يُرجع حالة `200 OK` إذا استجابت جميع الخوادم الوجهة لطلب ping الخاص بها بـ `200` أو `417 Expectation Failed` إذا استجاب أي من الخوادم برمز غير 200. كما يُرجع نص json مع تفاصيل حول الخدمات الناجحة/الفاشلة.
بالإضافة إلى نقاط النهاية أعلاه، يدعم reproxy فحوصات الصحة الحية الاختيارية. في هذه الحالة (إذا تم تمكينها)، يتم فحص كل وجهة للاستجابة لـ ping بشكل دوري ويتم استبعاد مسارات الوجهة الفاشلة. من الممكن إرجاع وجهات متطابقة متعددة من نفس المزود أو من مزودين مختلفين، ويتم اختيار الناجح فقط. إذا تم اكتشاف عدة تطابقات ونجحت، يتم اختيار التطابق النهائي وفقًا لاستراتيجية `lb-type` (بشكل افتراضي اختيار عشوائي).
لتشغيل فحص الصحة الحي، يجب على المستخدم تعيين `--health-check.enabled` (أو المتغير البيئي `HEALTH_CHECK_ENABLED=true`). لتخصيص فترة الفحص، يمكن استخدام `--health-check.interval=`.
## واجهة برمجة تطبيقات الإدارة
اختيارية، يمكن تفعيلها باستخدام `--mgmt.enabled`. تعرض نقطتي نهاية على `mgmt.listen` (address:port):
- `GET /routes` - قائمة بجميع المسارات المكتشفة
- `GET /metrics` - تُرجع مقاييس بروميثيوس (`http_requests_total`, `response_status` و `http_response_time_seconds`)
افتراضيًا، يستخدم `http_response_time_seconds` مسارات الطلب الخام كتسميات، مما قد يتسبب في عدد مرتفع من القيم الفريدة مع عناوين URL الديناميكية (مثل `/api/users/123`, `/api/users/456`). استخدم `--mgmt.low-cardinality` للتبديل إلى أنماط المسار (مثل `^/api/users/(.*)`) بدلاً من ذلك، مما يقلل بشكل كبير من عدد القيم الفريدة للمقاييس.
_انظر أيضًا [أمثلة/مقاييس](https://github.com/umputun/reproxy/tree/master/examples/metrics)_
## تقارير الأخطاء
يُرجع Reproxy خطأ 502 (Bad Gateway) في حالة عدم تطابق الطلب مع أي من المسارات والأصول المقدمة. في حالة حدوث خطأ داخلي غير متوقع، يُرجع 500. افتراضيًا، يعرض reproxy أبسط نسخة نصية من الخطأ - "Server error". تعيين `--error.enabled` يُفعّل رسالة الخطأ الافتراضية بتنسيق html ومع `--error.template` يمكن للمستخدم تعيين أي ملف قالب html مخصص لعرض الخطأ. يحتوي القالب على متغيرين: `{{.ErrCode}}` و `{{.ErrMessage}}`. على سبيل المثال، سيتم تحويل هذا القالب `oh my! {{.ErrCode}} - {{.ErrMessage}}` إلى `oh my! 502 - Bad Gateway`
## التحديد (Throttling)
يسمح Reproxy بتعيين قيمة حد أقصى للطلبات/الثانية للنظام بشكل عام وكذلك لكل مستخدم. القيمة 0 (الافتراضية) تُعتبر غير محدودة.
نشاط المستخدم محدود لكل من المسارات المتطابقة وغير المتطابقة. جميع المسارات غير المتطابقة تُعتبر "مجموعة وجهة واحدة" وتحصل على محدد مشترك وهو `rate*3`. هذا يعني أنه إذا تم تعريف 10 (طلب/ثانية) باستخدام `--throttle.user=10`، فسيتمكن المستخدم النهائي من تنفيذ ما يصل إلى 30 طلبًا في الثانية إما للأصول الثابتة أو المسارات غير المتطابقة. بالنسبة للمسارات المتطابقة، يتم الحفاظ على هذا المحدد لكل وجهة (مسار)، أي أن الطلب الذي يتم توجيهه إلى s1.example.com/api سيسمح بـ 10 طلبات/ثانية والطلب الموجه إلى s2.example.com سيسمح بـ 10 طلبات/ثانية أخرى.
### المهلة الزمنية والتحديد لكل مسار
يمكن للمسارات الفردية تجاوز الإعدادات العامة `--timeout.write` و `--throttle.user` عبر حقلي `timeout` و `throttle` الخاصين بالمزود. هذا مفيد لنقاط النهاية طويلة المدى (مثل التحميلات، إنشاء التقارير) التي تحتاج إلى مهلة زمنية أعلى من مهلة الكتابة العامة، ولتشديد حدود المعدل على المسارات الحساسة (مثل تسجيل الدخول) دون رفع السقف العالمي لبقية المسارات.
الأولوية هي "الصفر يرث العام، القيمة الموجبة تتجاوز": المسار الذي يحتوي على `timeout: 0` (أو بدون حقل `timeout`) يحتفظ بالمهلة الزمنية العامة `--timeout.write`؛ المسار الذي يحتوي على `timeout: 5m` يتجاوزها للطلبات المتطابقة فقط. نفس القاعدة تنطبق على `throttle`.
المهلة الزمنية لكل مسار تتجاوز مهلات القراءة والكتابة للاتصال للطلبات المتطابقة، لذلك يمكن أن تتجاوز المهلة العامة `--timeout.write` (الافتراضية 30 ثانية). المسارات التي لا تحتوي على مهلة زمنية لكل مسار لا تزال تلتزم بالإعداد العام.
**حد — مهلة رأس استجابة على مستوى النقل:** المهلة الزمنية لكل مسار `timeout` لا تتجاوز `--timeout.resp-header` (الافتراضية 5 ثوان). يتم تعيين تلك المهلة على `http.Transport` المشترك وتطبق قبل أن يبدأ المنبع في إرسال رؤوس الاستجابة. إذا استغرق المنبع وقتًا أطول من `--timeout.resp-header` لبدء استجابته (مثل نقطة نهاية تقرير بطيئة)، يفشل الطلب عند ذلك الحد بغض النظر عن المهلة الزمنية لكل مسار. لدعم هذه المسارات، قم برفع `--timeout.resp-header` عالميًا إلى الحد الأقصى المطلوب لأي مسار بطيء الاستجابة. تجاوز المهلات الزمنية على مستوى النقل لكل مسار هو خارج النطاق عمدًا.
صيغة المزود:
- **مزود الملفات** (YAML): `timeout: 5m`, `throttle: 2`
- **المزود الثابت** (CSV): الحقول الموضعية السادس والسابع، مثل `*,^/upload/(.*),http://up:8080/$1,,,5m,2`
- **مزود Docker**: `reproxy.timeout=5m`, `reproxy.throttle=2` (أو `reproxy.<n>.timeout` / `reproxy.<n>.throttle` لحاويات متعددة المسارات)
- **مزود Consul Catalog**: `reproxy.timeout=5m`, `reproxy.throttle=2`
## حدود اتصال المنبع
يسمح Reproxy بتكوين إعدادات تجميع اتصالات المنبع للتحكم في عدد الاتصالات التي يتم الحفاظ عليها مع الخوادم الخلفية:
- `--upstream.max-idle-conns` - الحد الأقصى لعدد الاتصالات الخاملة عبر جميع مضيفات المنبع. الافتراضي: 100.
- `--upstream.max-conns` - الحد الأقصى لعدد الاتصالات لكل مضيف منبع (0 = غير محدود). الافتراضي: 0.
تعيين `--upstream.max-conns` يحد من الاتصالات المتزامنة لكل خادم خلفي، وهو مفيد عندما تكون للخوادم المنبع سعة محدودة أو لمنع استنزاف الاتصالات.
## المصادقة الأساسية
يدعم Reproxy المصادقة الأساسية في وضعين: عام (جميع المسارات) ولكل مسار.
### المصادقة الأساسية العامة
المصادقة الأساسية العامة تحمي جميع المسارات. هذا مفيد لحماية نقاط النهاية أثناء التطوير والاختبار. لتمكينها، قم بتعيين ملف htpasswd باستخدام `--basic-htpasswd=<موقع الملف>` أو المتغير البيئي `BASIC_HTPASSWD=<موقع الملف>`.
يتوقع Reproxy أن يكون ملف htpasswd بالتنسيق التالي:```
username1:bcrypt(password1)
username2:bcrypt(password2)
...
يمكن إنشاء ذلك باستخدام الأمر htpasswd -nbB، أي htpasswd -nbB test passwd
المصادقة لكل مسار تسمح باستخدام بيانات اعتماد مختلفة لمسارات مختلفة. عندما يكون للمسار مصادقة لكل مسار مكوّنة، يتم تجاوز المصادقة العامة لهذا المسار. يتم تكوين المصادقة لكل مسار عبر إعدادات خاصة بالموفر:
auth في YAML، على سبيل المثال: auth: "user1:$2y$..., user2:$2y$..."reproxy.authreproxy.authالتنسيق عبارة عن قائمة مفصولة بفواصل من أزواج user:bcrypt_hash (نفس تنسيق htpasswd). يمكن تحديد عدة مستخدمين لنفس المسار.
مثال مع docker-compose:```yaml services: admin-api: labels: - "reproxy.route=^/admin/(.*)" - "reproxy.dest=/$1" - "reproxy.auth=admin:$$2y$$05$$hashedpassword"
ملاحظة: في docker-compose، يجب هروب `$` إلى `$$`.
## التحكم في الوصول المستند إلى عنوان IP
يتيح Reproxy تقييد الوصول إلى المسارات باستخدام قائمة من الشبكات الفرعية أو عناوين IP مفصولة بفواصل. هذا مفيد للتطوير والاختبار قبل السماح بالوصول غير المقيد إليها. يمكن استخدامه أيضًا لتقييد الوصول إلى الخدمات الداخلية. بشكل افتراضي، جميع المسارات مفتوحة لجميع العملاء.
لتقييد الوصول إلى المسارات، يجب على المستخدم تعيين المفاتيح المناسبة للمسارات، أي `reproxy.remote` لـ docker و consul، و `remote` لموفر الملفات. يجب أن تكون القيمة قائمة من الشبكات الفرعية أو عناوين IP أو الشبكات الفرعية مفصولة بفواصل. على سبيل المثال `127.0.0.1, 192.168.1.0/24`. لمزيد من التفاصيل، راجع أقسام [موفر docker](#docker-provider) و [موفر كتالوج consul](#consul-catalog-provider).
بشكل افتراضي، سيتحقق reproxy من العنوان البعيد من طلب العميل. ومع ذلك، في بعض الحالات، لن يعمل كما هو متوقع، على سبيل المثال خلف وكيل آخر، أو مع شبكة جسر docker. يمكن تعديل ذلك باستخدام المعلمة `--remote-lookup-headers` التي تسمح بالتحقق من قيمة الرأس `X-Real-IP` أو `X-Forwarded-For` (بهذا الترتيب) واستخدامها للتحقق. إذا لم يتم تعيين الرأس، فسيتم إجراء التحقق مقابل العنوان البعيد للعميل. يتم توفير هذه الرؤوس من قبل العميل ويمكن تزويرها بسهولة، لذلك يجب تمكين هذه المعلمة فقط عندما يعمل reproxy خلف وكيل أمامي موثوق يقوم دائمًا بتعيين هذه الرؤوس والكتابة فوقها.
يجب استخدام التحقق من الرؤوس بحذر، حيث أنه من الممكن تزويرها. عند تمكين `--remote-lookup-headers`، فإن القائمة البيضاء لعناوين IP تعتمد بالكامل على افتراض الثقة هذا: يمكن للعميل الذي يرسل `X-Real-IP` أو `X-Forwarded-For` بعنوان مسموح به تجاوز القيد. قم بتمكين هذا الخيار فقط إذا كان reproxy خلف وكيل موثوق يتحكم في هذه الرؤوس ويمكنك ضمان عدم تزويرها.
## دعم الإضافات
يمكن توسيع الوظائف الأساسية لـ reproxy بإضافات خارجية. كل إضافة هي عملية/حاوية مستقلة تنفذ [خادم rpc](https://golang.org/pkg/net/rpc/). يتم تسجيل الإضافات مع موصل reproxy وإضافتها إلى سلسلة الوسائط الوسيطة. تتلقى كل إضافة طلبًا بعنوان URL الأصلي والرؤوس وجميع معلومات المسار المطابق وتستجيب بالرؤوس ورمز الحالة. يتم التعامل مع أي رمز حالة >= 400 كاستجابة خطأ وينهي التدفق فورًا مع خطأ الوكيل. يوجد نوعان من الرؤوس يمكن للإضافات تعيينها:
- `HeadersIn` - الرؤوس الواردة. سيتم إرسالها إلى عنوان URL الوكيل
- `HeadersOut` - الرؤوس الصادرة. سيتم إرسالها مرة أخرى إلى العميل
بشكل افتراضي، سيتم خلط الرؤوس التي تحددها الإضافة مع الرؤوس الأصلية. في حالة احتياج الإضافة للتحكم في جميع الرؤوس، على سبيل المثال إسقاط بعضها، يمكن للإضافة تعيين حقل `OverrideHeaders*` للإشارة إلى عملية reproxy الأساسية بضرورة الكتابة فوق جميع الرؤوس بدلاً من خلطها.
- `OverrideHeadersIn` - يشير إلى أن الإضافة مسؤولة عن جميع الرؤوس الواردة.
- `OverrideHeadersOut` - يشير إلى أن الإضافة مسؤولة عن جميع الرؤوس الصادرة
لتبسيط عملية التطوير، يتم توفير جميع اللبنات الأساسية. يتضمن ذلك `lib.Plugin` الذي يتعامل مع التسجيل والاستماع وتوزيع الاستدعاءات بالإضافة إلى `lib.Request` و `lib.Response` اللذين يحددان المدخلات والمخرجات. يجب على مؤلفي الإضافات تنفيذ معالجات محددة تفي بتوقيع الدالة `func(req lib.Request, res *lib.HandlerResponse) (err error)`. يمكن أن تحتوي كل إضافة على معالجات متعددة مثل هذه.
_راجع [أمثلة/إضافة](https://github.com/umputun/reproxy/tree/master/examples/plugin) لمزيد من المعلومات_
## أمان الحاوية
بشكل افتراضي، تعمل حاوية reproxy تحت المستخدم الجذر لتبسيط الإعداد الأولي والوصول إلى مقبس docker. هذا ضروري للسماح لموفر docker باكتشاف الحاويات قيد التشغيل. ومع ذلك، إذا لم يكن هذا الاكتشاف مطلوبًا أو لم يكن موفر docker قيد الاستخدام، فمن المستحسن تغيير المستخدم إلى مستخدم أقل صلاحية. يمكن القيام بذلك على مستوى docker-compose وعلى مستوى docker باستخدام خيار `user`، راجع القسم أدناه للحصول على التفاصيل.
في بعض الأحيان، حتى مع التوجيه داخل docker، من المنطقي تعطيل موفر docker وإعداد القواعد باستخدام موفر ثابت أو ملف. جميع الحاويات التي تعمل داخل compose تشارك نفس الشبكة ويمكن الوصول إليها عبر DNS المحلي. يمكن للمستخدم الحصول على قاعدة مثل هذه لتجنب اكتشاف docker: `- STATIC_RULES=*,/api/email/(.*),http://email-sender:8080/$$1`. تتوقع هذه القاعدة وجود حاوية `email-sender` محددة داخل نفس compose. يرجى الملاحظة: يمكن للمستخدمين تحقيق نفس النتيجة باستخدام شبكة docker حتى إذا تم تعريف الخدمة الوجهة في ملف compose مختلف. بهذه الطريقة، يمكن أن يظل تكوين reproxy منفصلاً عن الخدمات الفعلية.
لا يوجد شيء سوى ملف reproxy الثنائي داخل حاوية reproxy، حيث يتم بناؤها فوق صورة فارغة (scratch).
### التشغيل بمستخدم غير جذر
يتم إنشاء مستخدم مسبقًا بمعرف UID `1001` (ينتمي إلى المجموعات `1001` و `999`) داخل الحاوية ويمكن استخدامه لتشغيل reproxy كمستخدم غير جذر:```yaml
services:
reproxy:
user: 1001
image: umputun/reproxy:latest
# <...>
# see examples/ssl/docker-compose.yml for the full file example
إذا كنت ترغب في استخدام موفر Docker، فستحتاج إلى التأكد من أن هذا المستخدم لديه إذن للوصول إلى مقبس Docker على النظام المضيف. تعتمد كيفية إعداد هذه الأذونات على تكوين النظام المضيف لديك. لمزيد من المعلومات حول تكوين أذونات مقبس Docker، راجع وثائق Docker حول تأمين مقبس خادم Docker.
يمكن تقديم كل خيار بشكلين: سطر الأوامر أو زوج مفتاح:قيمة من البيئة. بعض خيارات سطر الأوامر لها شكل قصير، مثل -l localhost:8080 وجميعها لها الشكل الطويل، أي --listen=localhost:8080. يتم إدراج مفتاح البيئة (الاسم) المدرج لكل خيار كلاحقة، أي [$LISTEN].
جميع خيارات الحجم تدعم لواحق الوحدات، أي 10K (أو 10k) للكيلوبايت، 16M (أو 16m) للميغابايت، 10G (أو 10g) للغيغابايت. عدم وجود أي لاحقة (أي 1024) يعني بايت.
بعض الخيارات قابلة للتكرار، في هذه الحالة يمكن للمستخدم تمريرها عدة مرات عبر سطر الأوامر، أو مفصولة بفواصل في البيئة. على سبيل المثال --ssl.fqdn هو خيار من هذا القبيل ويمكن تمريره كـ --ssl.fqdn=a1.example.com --ssl.fqdn=a2.example.com أو كمتغير بيئة SSL_ACME_FQDN=a1.example.com,a2.example.com
هذه قائمة بجميع الخيارات التي تدعم عناصر متعددة:
ssl.fqdn (SSL_ACME_FQDN)assets.cache (ASSETS_CACHE)docker.exclude (DOCKER_EXCLUDE)static.rule ($STATIC_RULES)header ($HEADER)drop-header ($DROP_HEADERS)-l, --listen= listen on host:port (default: 0.0.0.0:8080/8443 under docker, 127.0.0.1:80/443 without) [$LISTEN]
-m, --max= max request size (default: 64K) [$MAX_SIZE]
-g, --gzip enable gz compression [$GZIP]
-x, --header= outgoing proxy headers to add [$HEADER]
--drop-header= incoming headers to drop [$DROP_HEADERS]
--basic-htpasswd= htpasswd file for basic auth [$BASIC_HTPASSWD]
--lb-type=[random|failover|roundrobin] load balancer type (default: random) [$LB_TYPE]
--signature enable reproxy signature headers [$SIGNATURE]
--remote-lookup-headers enable remote lookup headers, trust only behind a trusted proxy [$REMOTE_LOOKUP_HEADERS]
--keep-host keep original Host header as default when proxying [$KEEP_HOST]
--insecure skip SSL verification on destination host [$INSECURE]
--dbg debug mode [$DEBUG]
ssl: --ssl.type=[none|static|auto] ssl (auto) support (default: none) [$SSL_TYPE] --ssl.cert= path to cert.pem file [$SSL_CERT] --ssl.key= path to key.pem file [$SSL_KEY] --ssl.acme-location= dir where certificates will be stored by autocert manager (default: ./var/acme) [$SSL_ACME_LOCATION] --ssl.acme-email= admin email for certificate notifications [$SSL_ACME_EMAIL] --ssl.http-port= http port for redirect to https and acme challenge test (default: 8080 under docker, 80 without) [$SSL_HTTP_PORT] --ssl.fqdn= FQDN(s) for ACME certificates [$SSL_ACME_FQDN]
assets: -a, --assets.location= assets location [$ASSETS_LOCATION] --assets.root= assets web root (default: /) [$ASSETS_ROOT] --assets.spa spa treatment for assets [$ASSETS_SPA] --assets.cache= cache duration for assets [$ASSETS_CACHE] --assets.not-found= path to file to serve on 404, relative to location [$ASSETS_NOT_FOUND]
logger: --logger.stdout enable stdout logging [$LOGGER_STDOUT] --logger.enabled enable access and error rotated logs [$LOGGER_ENABLED] --logger.file= location of access log (default: access.log) [$LOGGER_FILE] --logger.max-size= maximum size before it gets rotated (default: 100M) [$LOGGER_MAX_SIZE] --logger.max-backups= maximum number of old log files to retain (default: 10) [$LOGGER_MAX_BACKUPS]
docker: --docker.enabled enable docker provider [$DOCKER_ENABLED] --docker.host= docker host (default: unix:///var/run/docker.sock) [$DOCKER_HOST] --docker.network= docker network [$DOCKER_NETWORK] --docker.exclude= excluded containers [$DOCKER_EXCLUDE] --docker.auto enable automatic routing (without labels) [$DOCKER_AUTO] --docker.prefix= prefix for docker source routes [$DOCKER_PREFIX] --docker.api-version= docker API version (default: 1.24) [$DOCKER_API_VERSION]
consul-catalog: --consul-catalog.enabled enable consul catalog provider [$CONSUL_CATALOG_ENABLED] --consul-catalog.address= consul address (default: http://127.0.0.1:8500) [$CONSUL_CATALOG_ADDRESS] --consul-catalog.interval= consul catalog check interval (default: 1s) [$CONSUL_CATALOG_INTERVAL]
file: --file.enabled enable file provider [$FILE_ENABLED] --file.name= file name (default: reproxy.yml) [$FILE_NAME] --file.interval= file check interval (default: 3s) [$FILE_INTERVAL] --file.delay= reload only after the file has been unchanged for this long (default: 500ms) [$FILE_DELAY]
static: --static.enabled enable static provider [$STATIC_ENABLED] --static.rule= routing rules [$STATIC_RULES]
timeout: --timeout.read-header= read header server timeout (default: 5s) [$TIMEOUT_READ_HEADER] --timeout.write= write server timeout (default: 30s) [$TIMEOUT_WRITE] --timeout.idle= idle server timeout (default: 30s) [$TIMEOUT_IDLE] --timeout.dial= dial transport timeout (default: 30s) [$TIMEOUT_DIAL] --timeout.keep-alive= keep-alive transport timeout (default: 30s) [$TIMEOUT_KEEP_ALIVE] --timeout.resp-header= response header transport timeout (default: 5s) [$TIMEOUT_RESP_HEADER] --timeout.idle-conn= idle connection transport timeout (default: 90s) [$TIMEOUT_IDLE_CONN] --timeout.tls= TLS hanshake transport timeout (default: 10s) [$TIMEOUT_TLS] --timeout.continue= expect continue transport timeout (default: 1s) [$TIMEOUT_CONTINUE]
mgmt: --mgmt.enabled enable management API [$MGMT_ENABLED] --mgmt.listen= listen on host:port (default: 0.0.0.0:8081) [$MGMT_LISTEN] --mgmt.low-cardinality use route patterns instead of raw paths for metrics labels [$MGMT_LOW_CARDINALITY]
error: --error.enabled enable html errors reporting [$ERROR_ENABLED] --error.template= error message template file [$ERROR_TEMPLATE]
health-check: --health-check.enabled enable automatic health-check [$HEALTH_CHECK_ENABLED] --health-check.interval= automatic health-check interval (default: 300s) [$HEALTH_CHECK_INTERVAL]
throttle: --throttle.system= throttle overall activity' (default: 0) [$THROTTLE_SYSTEM] --throttle.user= limit req/sec per user and per proxy destination (default: 0) [$THROTTLE_USER]
upstream: --upstream.max-idle-conns= max idle connections total (default: 100) [$UPSTREAM_MAX_IDLE_CONNS] --upstream.max-conns= max connections per upstream host (0=unlimited) (default: 0) [$UPSTREAM_MAX_CONNS]
plugin: --plugin.enabled enable plugin support [$PLUGIN_ENABLED] --plugin.listen= registration listen on host:port (default: 127.0.0.1:8081) [$PLUGIN_LISTEN]
Help Options: -h, --help Show this help message
## الحالة
المشروع قيد التطوير النشط وقد تحدث تغييرات جذرية حتى إصدار `v1`. ومع ذلك، نبذل قصارى جهدنا لتجنب كسر التوافق ما لم يكن هناك سبب وجيه. اعتبارًا من الإصدار 0.4.x، يُعتبر reproxy جيدًا بما يكفي للاستخدام الفعلي، والعديد من الإعدادات تشغّله في الإنتاج.
example.com,^/login,https://api.example.com/login,,,,2 - تحديد 2 طلب/ثانية لكل مستخدم لكل مسار (الحقول السابقة تُترك فارغة).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.true