reproxy v1.7.1 — Lightweight edge HTTP(S) server and reverse proxy with automatic SSL, Docker/Consul discovery, per-route authentication, rate limiting, and health-check-based failover.

Reproxy एक सरल एज HTTP(s) सर्वर / रिवर्स प्रॉक्सी है जो विभिन्न प्रदाताओं (डॉकर, स्टैटिक, फ़ाइल, कॉन्सल कैटलॉग) का समर्थन करता है। एक या अधिक प्रदाता अनुरोधित सर्वर, अनुरोधित URL, गंतव्य URL और हेल्थ चेक URL के बारे में जानकारी प्रदान करते हैं। इसे एकल बाइनरी या डॉकर कंटेनर के रूप में वितरित किया जाता है।

Let's Encrypt के साथ स्वचालित SSL समाप्ति
उपयोगकर्ता द्वारा प्रदान किए गए SSL प्रमाणपत्रों का समर्थन
सरल लेकिन लचीले प्रॉक्सी नियम
स्थिर, कमांड-लाइन प्रॉक्सी नियम प्रदाता
गतिशील, फ़ाइल-आधारित प्रॉक्सी नियम प्रदाता
स्वचालित खोज के साथ डॉकर प्रदाता
सेवा टैग द्वारा खोज के साथ कॉन्सल कैटलॉग प्रदाता
एकाधिक (वर्चुअल) होस्ट के लिए समर्थन
वैकल्पिक ट्रैफ़िक संपीड़न
वैकल्पिक IP-आधारित पहुँच नियंत्रण
प्रति-रूट मूल प्रमाणीकरण
उपयोगकर्ता-परिभाषित आकार सीमाएँ और टाइमआउट
एकल बाइनरी वितरण
डॉकर कंटेनर वितरण
वैकल्पिक "SPA फ्रेंडली" मोड के साथ अंतर्निहित स्थिर संपत्ति सर्वर
रीडायरेक्ट नियमों के लिए समर्थन
समग्र गतिविधि के साथ-साथ उपयोगकर्ता की गतिविधि के लिए वैकल्पिक सीमक
लाइव हेल्थ चेक और फ़ेल-ओवर/लोड-बैलेंसिंग
रूट जानकारी और प्रोमेथियस मेट्रिक्स के साथ प्रबंधन सर्वर
कस्टम कार्यक्षमता लागू करने के लिए RPC के माध्यम से प्लगइन्स का समर्थन
अपाचे लॉग फ़ॉर्मेट और सरलीकृत stdout रिपोर्ट दोनों के साथ वैकल्पिक लॉगिंग।

सर्वर (होस्ट) को 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.auto
डॉकर कंटेनर के रूप में: 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 एक छोटे स्व-निहित बाइनरी के साथ-साथ डॉकर इमेज के रूप में वितरित किया जाता है। बाइनरी और इमेज दोनों कई आर्किटेक्चर और कई ऑपरेटिंग सिस्टम का समर्थन करते हैं, जिनमें linux_x86_64, linux_arm64, linux_arm, macos_x86_64, macos_arm64, windows_x86_64 और windows_arm शामिल हैं। हम arm64 और x86 deb और rpm पैकेज भी प्रदान करते हैं।

बाइनरी वितरण के लिए रिलीज़ सेक्शन में उपयुक्त फ़ाइल डाउनलोड करें
Homebrew उपयोगकर्ताओं के लिए: brew install umputun/apps/reproxy
डॉकर कंटेनर Docker Hub और Github Container Registry पर उपलब्ध है। उदाहरण के लिए, docker pull umputun/reproxy या docker pull ghcr.io/umputun/reproxy।

नवीनतम स्थिर संस्करण में :vX.Y.Z डॉकर टैग है (:latest उपनाम के साथ) और वर्तमान मास्टर में :master टैग है।

प्रदाता

प्रॉक्सी नियम विभिन्न प्रदाताओं द्वारा प्रदान किए जाते हैं। वर्तमान में शामिल हैं - file, docker, static और consul-catalog। प्रत्येक प्रदाता प्रॉक्सी किए गए अनुरोध और स्थिर (संपत्ति) दोनों के लिए कई रूटिंग नियम परिभाषित कर सकता है। उपयोगकर्ता एक ही समय में कई प्रदाता सेट कर सकता है।

विभिन्न प्रदाताओं के उदाहरण examples में देखें

स्थिर प्रदाता

यह सबसे सरल प्रदाता है जो सभी मैपिंग नियमों को सीधे कमांड लाइन (या पर्यावरण) में परिभाषित करता है। कई नियम समर्थित हैं। प्रत्येक नियम 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 url वाले सभी अनुरोधों को 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 - प्रति उपयोगकर्ता 2 req/sec का प्रति-रूट थ्रॉटल (पहले के पोज़िशनल फ़ील्ड खाली छोड़े गए)

चौथा तत्व वैकल्पिक पिंग url को परिभाषित करता है जिसका उपयोग हेल्थ रिपोर्टिंग के लिए किया जाता है। पाँचवाँ तत्व वैकल्पिक रूप से बैकएंड पर हेल्थ चेक अनुरोधों को अग्रेषित करने को सक्षम करता है (true, yes, 1)। अधिक जानकारी के लिए हेल्थ चेक अनुभाग देखें। छठा तत्व एक वैकल्पिक प्रति-रूट अनुरोध टाइमआउट है (Go अवधि, जैसे 5m, 30s); 0 या खाली वैश्विक --timeout.write सेटिंग प्राप्त करता है। सातवाँ तत्व एक वैकल्पिक प्रति-रूट प्रति उपयोगकर्ता req/sec सीमा है; 0 या खाली --throttle.user प्राप्त करता है। खाली पोज़िशनल फ़ील्ड की अनुमति है (जैसे अप्रयुक्त मध्य फ़ील्ड के लिए ,,)।

फ़ाइल प्रदाता

यह प्रदाता रूटिंग नियमों के साथ 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/) होना चाहिए, रेगेक्स नहीं। ^/(.*) जैसे रेगेक्स पैटर्न assets: true के साथ काम नहीं करेंगे क्योंकि स्थैतिक एसेट मिलान पथ उपसर्ग तुलना का उपयोग करता है, रेगेक्स का नहीं।

Docker प्रदाता

Docker प्रदाता बिना किसी अतिरिक्त कॉन्फ़िगरेशन के पूर्णतः स्वचालित खोज (--docker.auto के साथ) का समर्थन करता है। डिफ़ॉल्ट रूप से, यह http://<url>/<container name>/(.*) जैसे सभी अनुरोधों को दिए गए कंटेनर के आंतरिक IP और उजागर पोर्ट पर रीडायरेक्ट करता है। केवल सक्रिय (चल रहे) कंटेनर का पता लगाया जाएगा।

इस डिफ़ॉल्ट को लेबल के साथ बदला जा सकता है:

reproxy.server - मिलान करने के लिए सर्वर (होस्टनेम)। यह अल्पविराम से अलग किए गए सर्वरों की सूची भी हो सकती है।
reproxy.route - स्रोत रूट (लोकेशन)
reproxy.dest - गंतव्य पथ। ध्यान दें: यह पूर्ण URL नहीं है, बल्कि केवल वह पथ है जो कंटेनर के ip:पोर्ट में जोड़ा जाएगा।
reproxy.port - खोजे गए कंटेनर के लिए गंतव्य पोर्ट
reproxy.ping - गंतव्य कंटेनर के लिए पिंग पथ।
reproxy.remote - अल्पविराम से अलग किए गए सबनेट या IP की सूची के साथ रूट तक पहुंच प्रतिबंधित करें।
reproxy.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 - प्रति-रूट req/sec सीमा प्रति उपयोगकर्ता। 0 या अनसेट --throttle.user को प्राप्त करता है। अमान्य या नकारात्मक मानों को चेतावनी के साथ अनदेखा किया जाता है।
reproxy.enabled - reproxy गंतव्यों से कंटेनर को सक्षम (yes, true, 1) या अक्षम (no, false, 0) करें।

कृपया ध्यान दें: --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 लेबल के कई सेट को परिभाषित करने की अनुमति भी देता है। यह उपयोगी है क्योंकि कुछ मामलों में एक एकल कंटेनर कई एंडपॉइंट प्रकट कर सकता है, उदाहरण के लिए, सार्वजनिक API और कुछ व्यवस्थापक API। उपरोक्त सभी लेबल "N-इंडेक्स" के साथ उपयोग किए जा सकते हैं, जैसे reproxy.1.server, reproxy.1.port इत्यादि। N 0 से 9 की सीमा में होना चाहिए।

यह एक गतिशील प्रदाता है और कंटेनर की स्थिति में कोई भी परिवर्तन स्वचालित रूप से लागू होगा।

Consul Catalog प्रदाता

उपयोग: reproxy --consul-catalog.enabled

Consul Catalog प्रदाता समय-समय पर (डिफ़ॉल्ट रूप से प्रति सेकंड) Consul API को कॉल करता है ताकि उन सेवाओं को प्राप्त किया जा सके जिनमें 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` - कॉमा-सेपरेटेड सबनेट या आईपी की सूची के साथ रूट तक पहुंच प्रतिबंधित करें
- `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` - प्रति-रूट req/sec सीमा प्रति उपयोगकर्ता। `0` या अनसेट `--throttle.user` से विरासत में मिलता है। अमान्य या नकारात्मक मान चेतावनी के साथ अनदेखा किए जाते हैं।
- `reproxy.enabled` - सेवा को reproxy गंतव्यों से सक्षम (`yes`, `true`, `1`) या अक्षम (`कोई भी अलग मान`) करें।

### कंपोज़-विशिष्ट विवरण

यदि नियम डॉकर कंपोज़ एनवायरनमेंट के हिस्से के रूप में सेट किए गए हैं, तो रेगेक्स समूह वाला गंतव्य कंपोज़ सिंटैक्स से टकराएगा। यानी, कंपोज़ एनवायरनमेंट में `https://api.example.com/$1` का उपयोग करने का प्रयास सिंटैक्स त्रुटि के कारण विफल हो जाएगा। यहाँ मानक समाधान `$` चिह्न को `$$` से बदलकर "एस्केप" करना है, यानी `https://api.example.com/$$1`। यह प्रतिस्थापन डॉकर कंपोज़ द्वारा समर्थित है और इसका reproxy से कोई लेना-देना नहीं है। दूसरा तरीका `$` के बजाय `@` का उपयोग करना है, जो reproxy स्तर पर समर्थित है, यानी `https://api.example.com/@1` है।

## SSL समर्थन

SSL मोड (डिफ़ॉल्ट रूप से none) को `auto` (ACME/LE प्रमाणपत्र), `static` (मौजूदा प्रमाणपत्र) या `none` पर सेट किया जा सकता है। यदि `auto` चालू किया जाता है, तो सभी खोजे गए सर्वर नामों के लिए SSL प्रमाणपत्र स्वचालित रूप से जारी किया जाएगा। उपयोगकर्ता `--ssl.fqdn` मान सेट करके इसे ओवरराइड कर सकता है। `auto` और `static` SSL मोड में, Reproxy स्वचालित रूप से `X-Forwarded-Proto` और `X-Forwarded-Port` हेडर जोड़ेगा। ये हेडर प्रॉक्सी के पीछे की सेवाओं के लिए उपयोगी हैं ताकि वे क्लाइंट द्वारा उपयोग किए जाने वाले मूल प्रोटोकॉल (http या https) और पोर्ट नंबर को जान सकें।

डिस्कवरी प्रदाताओं (डॉकर, फ़ाइल, कंसल) के साथ ACME का उपयोग करते समय, नए खोजे गए सर्वरों के लिए reproxy पुनरारंभ की आवश्यकता के बिना SSL प्रमाणपत्र स्वचालित रूप से प्राप्त किए जाते हैं।

### ACME चुनौतियाँ

Reproxy SSL प्रमाणपत्र सत्यापन के लिए दो प्रकार की ACME चुनौतियों का समर्थन करता है:

1. **HTTP-01 चुनौती** (डिफ़ॉल्ट): एक विशिष्ट HTTP URL पर एक टोकन प्रस्तुत करके डोमेन स्वामित्व को सत्यापित करता है। इसके लिए पोर्ट 80 को सार्वजनिक रूप से सुलभ होना आवश्यक है।

2. **DNS-01 चुनौती**: DNS TXT रिकॉर्ड बनाकर डोमेन स्वामित्व को सत्यापित करता है। यह विधि:
   - पोर्ट 80 को सुलभ होने की आवश्यकता नहीं है
   - वाइल्डकार्ड प्रमाणपत्रों के साथ काम करता है
   - एक समर्थित DNS प्रदाता कॉन्फ़िगरेशन की आवश्यकता है

#### चुनौती चयन

Reproxy आपके कॉन्फ़िगरेशन के आधार पर स्वचालित रूप से निर्धारित करता है कि किस चुनौती विधि का उपयोग करना है:

- **HTTP-01** (डिफ़ॉल्ट): जब कोई DNS प्रदाता कॉन्फ़िगर नहीं किया गया हो तो उपयोग किया जाता है
- **DNS-01**: जब कोई DNS प्रदाता कॉन्फ़िगर किया गया हो तो उपयोग किया जाता है

आपको स्पष्ट रूप से चुनौती प्रकार चुनने की आवश्यकता नहीं है - बस यदि आप DNS-01 चुनौतियों का उपयोग करना चाहते हैं तो DNS प्रदाता कॉन्फ़िगर करें।

#### वर्तमान में समर्थित 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`

DNS प्रदाता के रूप में Cloudflare के साथ उदाहरण:```
export CLOUDFLARE_API_TOKEN=your_api_token
reproxy --ssl.type=auto [email protected] --ssl.fqdn=example.com

DNS-01 चुनौती विशेष रूप से तब उपयोगी होती है जब:

आपके सर्वर पर पोर्ट 80 सार्वजनिक रूप से खुला न हो
आपको वाइल्डकार्ड प्रमाणपत्र चाहिए (जैसे, *.example.com)
आप प्रतिबंधात्मक फ़ायरवॉल के पीछे हों

हेडर्स

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 पैरामीटर (दोहराया जा सकता है) या env HEADER के साथ किया जा सकता है। उदाहरण के लिए, डॉकर कंपोज़ के साथ इसे इस प्रकार किया जा सकता है:```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) है।

उपयोगकर्ता `--logger.stdout` के साथ 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 स्थिर सामग्री के लिए एक साधारण वेब सर्वर के रूप में कार्य करता है। एसेट्स सर्वर --assets.spa के साथ "spa मोड" का भी समर्थन करता है, जहां सभी न मिले अनुरोधों को index.html पर अग्रेषित किया जाता है।

सामान्य एसेट्स सर्वर के अतिरिक्त, कई कस्टम एसेट्स सर्वर समर्थित हैं। प्रत्येक प्रदाता के पास ऐसा स्थिर नियम परिभाषित करने का एक अलग तरीका होता है, और कुछ प्रदाता इसका बिल्कुल भी समर्थन नहीं कर सकते हैं। उदाहरण के लिए, कई एसेट सर्वर स्थिर (कमांड लाइन प्रदाता), फ़ाइल प्रदाता, और डॉकर प्रदाताओं के साथ भी उपयोगी होते हैं, हालांकि consul कैटलॉग प्रदाता के साथ इसका बहुत कम मतलब है।

स्थिर प्रदाता - यदि स्रोत तत्व assets: या spa: से उपसर्गित है, तो इसे फ़ाइल-सर्वर के रूप में माना जाएगा। उदाहरण के लिए *,assets:/web,/var/www, /var/www निर्देशिका के शीर्ष पर फ़ाइल सर्वर के साथ सभी /web/* अनुरोधों को सर्व करेगा।
फ़ाइल प्रदाता - वैकल्पिक फ़ील्ड assets: true या spa: true सेट करना। नोट: route फ़ील्ड एक पथ उपसर्ग (जैसे, /, /web/) होना चाहिए, regex पैटर्न नहीं।
डॉकर प्रदाता - reproxy.assets=web-root:location, अर्थात reproxy.assets=/web:/var/www। spa मोड में स्विच करना reproxy.spa को yes या true पर सेट करके किया जाता है।

कैशिंग

एसेट्स सर्वर --assets.cache=<अवधि> पैरामीटर के साथ कैशिंग नियंत्रण का समर्थन करता है। 0s अवधि (डिफ़ॉल्ट) कैशिंग नियंत्रण को बंद कर देती है। एक अवधि दशमलव संख्याओं का एक क्रम है, प्रत्येक वैकल्पिक अंश और एक इकाई प्रत्यय के साथ, जैसे "300ms", "1.5h" या "2h45m"। मान्य समय इकाइयाँ "ns", "us" (या "µs"), "ms", "s", "m", "h" और "d" हैं।

कैश अवधि सेट करने के दो तरीके हैं:

सभी स्थिर एसेट्स के लिए एक एकल मान। यह उतना ही सरल है जितना --assets.cache=48h।
विभिन्न mime प्रकारों के लिए कस्टम अवधि। इसमें दो भाग शामिल होने चाहिए - डिफ़ॉल्ट मान और mime:अवधि के जोड़े। कमांड लाइन में यह एकाधिक --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=<पथ> पैरामीटर के साथ सेट किया जा सकता है। पथ एसेट्स रूट के सापेक्ष होना चाहिए।

reproxy को बेस इमेज के रूप में उपयोग करना

विशुद्ध रूप से स्थिर सामग्री सर्व करना लोकप्रिय उपयोग मामलों में से एक है। आमतौर पर इसका उपयोग अलग फ्रंटएंड कंटेनर के लिए किया जाता है जो केवल UI प्रदान करता है। एसेट्स सर्वर के साथ ऐसा कंटेनर बनाना लगभग तुच्छ है। यह 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"]

All it needs is to copy stastic assets to some location and passing this location as `"--assets.location` to reproxy entrypoint.

## SPA-अनुकूल मोड

कुछ SPA एप्लिकेशन प्रॉक्सी पर निर्भर करते हैं कि वह स्थिर संपत्ति पर 404 को एक विशेष तरीके से संभाले, इसे "/index.html" पर रीडायरेक्ट करके। यह nginx के `try_files $uri $uri/ …` डायरेक्टिव के समान है और, जाहिर है, यह कार्यक्षमता आधुनिक वेब ऐप्स के लिए कुछ हद तक महत्वपूर्ण है।

यह मोड डिफ़ॉल्ट रूप से बंद है और `--assets.spa` या `ASSETS_SPA=true` env सेट करके चालू किया जा सकता है।

## रीडायरेक्ट

डिफ़ॉल्ट रूप से reproxy गंतव्य को एक प्रॉक्सी स्थान के रूप में मानता है, अर्थात यह आंतरिक रूप से http कॉल करता है और क्लाइंट को प्रतिक्रिया लौटाता है। हालांकि गंतव्य URL को `@code` के साथ उपसर्ग करके इस व्यवहार को स्थायी (स्टेटस कोड 301) या अस्थायी (स्टेटस कोड 302) रीडायरेक्ट में बदला जा सकता है। उदाहरण के लिए, गंतव्य को `@301 https://example.com/something` पर सेट करने से `Location: https://example.com/something` पर स्थायी http रीडायरेक्ट होगा।

समर्थित कोड:

- `@301`, `@perm` - स्थायी रीडायरेक्ट
- `@302`, `@temp`, `@tmp` - अस्थायी रीडायरेक्ट

## अधिक विकल्प

- `--gzip`   प्रतिक्रियाओं के लिए gzip संपीड़न सक्षम करता है।
- `--max=N`  अनुरोध का अधिकतम आकार सेट करने की अनुमति देता है (डिफ़ॉल्ट 64k)। इसे `0` पर सेट करने से आकार जांच अक्षम हो जाती है।
- `--timeout.*` सर्वर और प्रॉक्सी ट्रांसपोर्ट दोनों के लिए विभिन्न टाइमआउट। [All Application Options](#all-application-options) में `timeout` सेक्शन देखें। शून्य या नकारात्मक मान का अर्थ है कोई टाइमआउट नहीं होगा।
- `--insecure` गंतव्य होस्ट पर SSL सत्यापन अक्षम करता है। यह स्व-हस्ताक्षरित प्रमाणपत्रों के लिए उपयोगी है।

## डिफ़ॉल्ट पोर्ट

कस्टम पैरामीटर/एनवायरनमेंट पास करने की आवश्यकता को समाप्त करने के लिए, डिफ़ॉल्ट `--listen` गतिशील है और सामान्य मामलों के लिए उचित और सहायक होने का प्रयास करता है:

- यदि उपयोगकर्ताओं द्वारा `--listen` में कुछ भी सेट किया गया है तो नीचे का सारा तर्क अनदेखा कर दिया जाता है और दिया गया host:port सीधे उपयोग किया जाता है।
- यदि उपयोगकर्ताओं द्वारा `--listen` में कुछ भी सेट नहीं किया गया है और reproxy डॉकर कंटेनर के बाहर चलता है, तो http मोड (`ssl.type=none`) के लिए डिफ़ॉल्ट `127.0.0.1:80` और ssl मोड (`ssl.type=auto` या `ssl.type=static`) के लिए `127.0.0.1:443` है।
- यदि उपयोगकर्ताओं द्वारा `--listen` में कुछ भी सेट नहीं किया गया है और reproxy डॉकर के अंदर चलता है, तो http मोड के लिए डिफ़ॉल्ट `0.0.0.0:8080` और ssl मोड के लिए `0.0.0.0:8443` है।

एक और डिफ़ॉल्ट इसी गतिशील तरीके से सेट किया गया है `--ssl.http-port`। डॉकर कंटेनर के अंदर चलने के लिए यह `8080` पर सेट होता है और बाहर `80` पर।

## पिंग, स्वास्थ्य जांच और फेल-ओवर

reproxy इस उद्देश्य के लिए दो एंडपॉइंट प्रदान करता है:

- `/ping` `pong` के साथ प्रतिक्रिया देता है और इंगित करता है कि reproxy चालू और चल रहा है
- `/health` `200 OK` स्थिति लौटाता है यदि सभी गंतव्य सर्वरों ने अपने पिंग अनुरोध पर `200` के साथ प्रतिक्रिया दी, या `417 Expectation Failed` यदि किसी भी सर्वर ने गैर-200 कोड के साथ प्रतिक्रिया दी। यह पास/फेल सेवाओं के बारे में विवरण के साथ json बॉडी भी लौटाता है।

उपरोक्त एंडपॉइंट के अलावा, reproxy वैकल्पिक लाइव स्वास्थ्य जांच का समर्थन करता है। इस मामले में (यदि सक्षम है), प्रत्येक गंतव्य को समय-समय पर पिंग प्रतिक्रिया के लिए जांचा जाता है और विफल गंतव्य मार्गों को बाहर रखा जाता है। एक ही या विभिन्न प्रदाताओं से कई समान गंतव्य लौटाना संभव है, और केवल पास हुए को चुना जाता है। यदि कई मैच खोजे गए और पास हुए - तो `lb-type` रणनीति के अनुसार अंतिम एक चुना जाता है (डिफ़ॉल्ट रूप से यादृच्छिक चयन)।

लाइव स्वास्थ्य जांच चालू करने के लिए, उपयोगकर्ता को `--health-check.enabled` (या env `HEALTH_CHECK_ENABLED=true`) सेट करना चाहिए। जांच अंतराल को अनुकूलित करने के लिए `--health-check.interval=` का उपयोग किया जा सकता है।

## प्रबंधन API

वैकल्पिक, `--mgmt.enabled` के साथ चालू किया जा सकता है। `mgmt.listen` (पता:पोर्ट) पर 2 एंडपॉइंट उजागर करता है:

- `GET /routes` - सभी खोजे गए मार्गों की सूची
- `GET /metrics` - prometheus मेट्रिक्स लौटाता है (`http_requests_total`, `response_status` और `http_response_time_seconds`)

डिफ़ॉल्ट रूप से, `http_response_time_seconds` कच्चे अनुरोध पथों को लेबल के रूप में उपयोग करता है, जो गतिशील URL (जैसे, `/api/users/123`, `/api/users/456`) के साथ उच्च कार्डिनैलिटी का कारण बन सकता है। इसके बजाय रूट पैटर्न (जैसे, `^/api/users/(.*)`) पर स्विच करने के लिए `--mgmt.low-cardinality` का उपयोग करें, जिससे मेट्रिक्स कार्डिनैलिटी काफी कम हो जाती है।

_see also [examples/metrics](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` के रूप में प्रस्तुत किया जाएगा।

## थ्रॉटलिंग

Reproxy समग्र सिस्टम गतिविधि के साथ-साथ प्रति उपयोगकर्ता के लिए सिस्टम स्तर का अधिकतम req/sec मान परिभाषित करने की अनुमति देता है। 0 मान (डिफ़ॉल्ट) असीमित माना जाता है।

उपयोगकर्ता गतिविधि मेल खाने वाले और बेमेल दोनों मार्गों के लिए सीमित है। सभी बेमेल मार्गों को "एकल गंतव्य समूह" माना जाता है और उन्हें एक सामान्य लिमिटर मिलता है जो `rate*3` है। इसका मतलब है कि यदि `--throttle.user=10` के साथ 10 (req/sec) परिभाषित किया गया है, तो अंतिम उपयोगकर्ता स्थिर संपत्तियों या बेमेल मार्गों के लिए प्रति सेकंड 30 अनुरोध तक करने में सक्षम होगा। मेल खाने वाले मार्गों के लिए यह लिमिटर प्रति गंतव्य (मार्ग) बनाए रखा जाता है, अर्थात s1.example.com/api पर प्रॉक्सी किया गया अनुरोध 10 r/s की अनुमति देगा और s2.example.com पर प्रॉक्सी किया गया अनुरोध एक और 10 r/s की अनुमति देगा।

### प्रति-मार्ग टाइमआउट और थ्रॉटल

व्यक्तिगत मार्ग प्रदाता-विशिष्ट `timeout` और `throttle` फ़ील्ड के माध्यम से वैश्विक `--timeout.write` और `--throttle.user` सेटिंग्स को ओवरराइड कर सकते हैं। यह लंबे समय तक चलने वाले एंडपॉइंट (जैसे अपलोड, रिपोर्ट जनरेशन) के लिए उपयोगी है जिन्हें वैश्विक राइट टाइमआउट से अधिक समय सीमा की आवश्यकता होती है, और संवेदनशील मार्गों (जैसे लॉगिन) पर दर सीमा को कड़ा करने के लिए बाकी सब के लिए वैश्विक सीमा बढ़ाए बिना।

प्राथमिकता "शून्य वैश्विक को प्राप्त करता है, सकारात्मक ओवरराइड करता है" है: `timeout: 0` (या कोई `timeout` फ़ील्ड नहीं) वाला मार्ग वैश्विक `--timeout.write` बनाए रखता है; `timeout: 5m` वाला मार्ग केवल मेल खाने वाले अनुरोधों के लिए इसे ओवरराइड करता है। यही नियम `throttle` पर लागू होता है।

प्रति-मार्ग टाइमआउट मेल खाने वाले अनुरोधों के लिए कनेक्शन के रीड और राइट डेडलाइन को ओवरराइड करता है, ताकि यह वैश्विक `--timeout.write` (डिफ़ॉल्ट 30s) से आगे बढ़ सके। प्रति-मार्ग टाइमआउट के बिना मार्ग अभी भी वैश्विक सेटिंग का सम्मान करते हैं।

**सीमा — ट्रांसपोर्ट-स्तरीय प्रतिक्रिया-हेडर टाइमआउट:** प्रति-मार्ग `timeout` `--timeout.resp-header` (डिफ़ॉल्ट 5s) को ओवरराइड नहीं करता है। वह टाइमआउट साझा `http.Transport` पर सेट होता है और अपस्ट्रीम द्वारा प्रतिक्रिया हेडर भेजना शुरू करने से पहले लागू होता है। यदि कोई अपस्ट्रीम अपनी प्रतिक्रिया शुरू करने में `--timeout.resp-header` से अधिक समय लेता है (जैसे धीमा रिपोर्ट एंडपॉइंट), तो प्रति-मार्ग `timeout` की परवाह किए बिना अनुरोध उस सीमा पर विफल हो जाता है। ऐसे मार्गों का समर्थन करने के लिए, किसी भी धीमी-प्रतिक्रिया मार्ग के लिए आवश्यक अधिकतम तक वैश्विक रूप से `--timeout.resp-header` बढ़ाएं। ट्रांसपोर्ट-स्तरीय टाइमआउट का प्रति-मार्ग ओवरराइड जानबूझकर दायरे से बाहर है।

प्रदाता सिंटैक्स:
- **फ़ाइल प्रदाता** (YAML): `timeout: 5m`, `throttle: 2`
- **स्थिर प्रदाता** (CSV): 6वाँ और 7वाँ स्थितीय फ़ील्ड, जैसे `*,^/upload/(.*),http://up:8080/$1,,,5m,2`
- **डॉकर प्रदाता**: `reproxy.timeout=5m`, `reproxy.throttle=2` (या मल्टी-रूट कंटेनरों के लिए `reproxy.<n>.timeout` / `reproxy.<n>.throttle`)
- **कॉन्सल कैटलॉग प्रदाता**: `reproxy.timeout=5m`, `reproxy.throttle=2`

## अपस्ट्रीम कनेक्शन सीमाएँ

Reproxy अपस्ट्रीम कनेक्शन पूल सेटिंग्स कॉन्फ़िगर करने की अनुमति देता है ताकि बैकएंड सर्वरों पर बनाए रखे गए कनेक्शनों की संख्या को नियंत्रित किया जा सके:

- `--upstream.max-idle-conns` - सभी अपस्ट्रीम होस्टों पर निष्क्रिय कनेक्शनों की अधिकतम संख्या। डिफ़ॉल्ट: 100।
- `--upstream.max-conns` - प्रति अपस्ट्रीम होस्ट कनेक्शनों की अधिकतम संख्या (0 = असीमित)। डिफ़ॉल्ट: 0।

`--upstream.max-conns` सेट करना प्रत्येक बैकएंड के समवर्ती कनेक्शनों को सीमित करता है, जो तब उपयोगी होता है जब अपस्ट्रीम सर्वरों की सीमित क्षमता हो या कनेक्शन थकावट को रोकने के लिए।

## बेसिक ऑथ

Reproxy बेसिक ऑथ को दो मोड में समर्थन करता है: वैश्विक (सभी मार्ग) और प्रति-मार्ग।

### वैश्विक बेसिक ऑथ

वैश्विक बेसिक ऑथ सभी मार्गों की रक्षा करता है। यह विकास और परीक्षण के दौरान एंडपॉइंट की सुरक्षा के लिए उपयोगी है। सक्षम करने के लिए, htpasswd फ़ाइल को `--basic-htpasswd=<file location>` या env `BASIC_HTPASSWD=<file location>` के साथ सेट करें।

Reproxy htpasswd फ़ाइल को निम्नलिखित प्रारूप में होने की अपेक्षा करता है:```
username1:bcrypt(password1)
username2:bcrypt(password2)
...

इसे htpasswd -nbB कमांड से जनरेट किया जा सकता है, जैसे htpasswd -nbB test passwd

प्रति-रूट बेसिक ऑथ

प्रति-रूट ऑथ विभिन्न रूटों के लिए अलग-अलग क्रेडेंशियल्स की अनुमति देता है। जब किसी रूट पर प्रति-रूट ऑथ कॉन्फ़िगर किया जाता है, तो उस रूट के लिए ग्लोबल ऑथ को बायपास कर दिया जाता है। प्रति-रूट ऑथ प्रदाता-विशिष्ट सेटिंग्स के माध्यम से कॉन्फ़िगर किया जाता है:

फ़ाइल प्रदाता: YAML में auth फ़ील्ड, उदा., auth: "user1:$2y$..., user2:$2y$..."
Docker प्रदाता: reproxy.auth लेबल
Consul कैटलॉग प्रदाता: reproxy.auth टैग
स्टैटिक प्रदाता: समर्थित नहीं (प्रति-रूट ऑथ के लिए फ़ाइल प्रदाता का उपयोग करें)

प्रारूप user:bcrypt_hash जोड़ियों की एक कॉमा-सेपरेटेड सूची है (वही htpasswd प्रारूप)। एक ही रूट के लिए एकाधिक उपयोगकर्ता निर्दिष्ट किए जा सकते हैं।

docker-compose के साथ उदाहरण:```yaml services: admin-api: labels: - "reproxy.route=^/admin/(.*)" - "reproxy.dest=/$1" - "reproxy.auth=admin:$$2y$$05$$hashedpassword"

नोट: डॉकर-कम्पोज़ में, `$` को `$$` के रूप में एस्केप किया जाना चाहिए।

## आईपी-आधारित एक्सेस नियंत्रण

Reproxy एक कॉमा-सेपरेटेड सबनेट या आईपी की सूची के साथ रूट्स तक पहुँच को प्रतिबंधित करने की अनुमति देता है। यह विकास और परीक्षण के लिए उपयोगी है, इससे पहले कि उन तक अप्रतिबंधित पहुँच की अनुमति दी जाए। इसका उपयोग आंतरिक सेवाओं तक पहुँच को प्रतिबंधित करने के लिए भी किया जा सकता है। डिफ़ॉल्ट रूप से, सभी रूट सभी क्लाइंट के लिए खुले हैं।

रूट्स तक पहुँच प्रतिबंधित करने के लिए, उपयोगकर्ता को रूट्स के लिए उपयुक्त कुंजियाँ सेट करनी चाहिए, यानी डॉकर और कॉन्सल के लिए `reproxy.remote`, और फ़ाइल प्रदाता के लिए `remote`। मान कॉमा-सेपरेटेड सबनेट या आईपी या सबनेट की सूची होनी चाहिए। उदाहरण के लिए `127.0.0.1, 192.168.1.0/24`। अधिक जानकारी के लिए [डॉकर प्रदाता](#docker-provider) और [कॉन्सल कैटलॉग प्रदाता](#consul-catalog-provider) अनुभाग देखें।

डिफ़ॉल्ट रूप से, reproxy क्लाइंट के अनुरोध से रिमोट पते की जाँच करेगा। हालाँकि, कुछ मामलों में, यह अपेक्षा के अनुसार काम नहीं करेगा, उदाहरण के लिए किसी अन्य प्रॉक्सी के पीछे, या डॉकर ब्रिज नेटवर्क के साथ। इसे `--remote-lookup-headers` पैरामीटर से बदला जा सकता है जो हेडर `X-Real-IP` या `X-Forwarded-For` (इस क्रम में) के मान की जाँच करने और इसका उपयोग जाँच के लिए करने की अनुमति देता है। यदि हेडर सेट नहीं है, तो जाँच क्लाइंट के रिमोट पते के विरुद्ध की जाएगी। ये हेडर क्लाइंट द्वारा प्रदान किए जाते हैं और इन्हें आसानी से नकली बनाया जा सकता है, इसलिए यह पैरामीटर केवल तभी सक्षम किया जाना चाहिए जब reproxy एक विश्वसनीय फ्रंटिंग प्रॉक्सी के पीछे चलता है जो हमेशा इन हेडर को सेट और ओवरराइट करता है।

हेडर की जाँच सावधानी से की जानी चाहिए, क्योंकि उन्हें नकली बनाना संभव है। जब `--remote-lookup-headers` सक्षम होता है, तो आईपी अनुमति सूची पूरी तरह से इस विश्वास धारणा पर निर्भर करती है: एक क्लाइंट जो अनुमत पते के साथ `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)` हस्ताक्षर को संतुष्ट करने वाले ठोस हैंडलर लागू करने चाहिए। प्रत्येक प्लगइन में इस तरह के कई हैंडलर हो सकते हैं।

_अधिक जानकारी के लिए [examples/plugin](https://github.com/umputun/reproxy/tree/master/examples/plugin) देखें_

## कंटेनर सुरक्षा

डिफ़ॉल्ट रूप से, reproxy कंटेनर प्रारंभिक सेटअप को सरल बनाने और डॉकर के सॉकेट तक पहुँचने के लिए रूट उपयोक्ता के अंतर्गत चलता है। चल रहे कंटेनरों की डॉकर प्रदाता खोज की अनुमति देने के लिए यह आवश्यक है। हालाँकि, यदि ऐसी खोज की आवश्यकता नहीं है या डॉकर प्रदाता उपयोग में नहीं है, तो उपयोगकर्ता को कम विशेषाधिकार वाले किसी उपयोगकर्ता में बदलने की अनुशंसा की जाती है। यह डॉकर-कम्पोज़ स्तर और डॉकर स्तर पर `user` विकल्प के साथ किया जा सकता है, विवरण के लिए नीचे अनुभाग देखें।

कभी-कभी, डॉकर के अंदर रूटिंग के साथ भी, डॉकर प्रदाता को अक्षम करना और स्थिर या फ़ाइल प्रदाता के साथ नियम सेट करना समझ में आता है। एक कम्पोज़ के भीतर चलने वाले सभी कंटेनर एक ही नेटवर्क साझा करते हैं और स्थानीय DNS के माध्यम से सुलभ होते हैं। उपयोगकर्ता डॉकर डिस्कवरी से बचने के लिए इस तरह का नियम रख सकता है: `- STATIC_RULES=*,/api/email/(.*),http://email-sender:8080/$$1`। यह नियम उसी कम्पोज़ के अंदर परिभाषित `email-sender` कंटेनर की अपेक्षा करता है। कृपया ध्यान दें: उपयोगकर्ता डॉकर नेटवर्क का उपयोग करके समान परिणाम प्राप्त कर सकते हैं, भले ही गंतव्य सेवा एक अलग कम्पोज़ फ़ाइल में परिभाषित की गई हो। इस तरह 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

## Status

The project is under active development and may have breaking changes till `v1` is released. However, we are trying our best not to break things unless there is a good reason. As of version 0.4.x, reproxy is considered good enough for real-life usage, and many setups are running it in production.