ServBay वेबसाइट को सार्वजनिक नेटवर्क पर प्रकाशित करें (रिवर्स प्रॉक्सी, टनल और पोर्ट फॉरवर्डिंग)

लोकल डेवेलपमेंट के अलावा, कई यूज़र्स ServBay को किसी स्थायी सर्वर (डेटा सेंटर का Mac mini, ऑफिस डेस्कटॉप, Windows सर्वर आदि) पर बतौर बैकएंड ओरिजिन सर्वर डिप्लॉय करते हैं और फिर वेबसाइट को पब्लिक एक्सेस के लिए जारी करते हैं। प्रोडक्शन में यह पूरी तरह व्यावहारिक है—कई यूज़र्स इस सेटअप को स्थिरता से चला रहे हैं।

लेकिन अगर आप ServBay के डिफ़ॉल्ट नेटवर्क व्यवहार को नहीं समझते हैं, तो प्रोटोकॉल, सर्टिफिकेट्स, Host हेडर, नेटवर्क आदि में दिक्कतें आ सकती हैं—जिससे “लोकल में सब सही है, लेकिन पब्लिक एक्सेस पर समस्या आ रही है” जैसी स्थिति बनती है। यह गाइड हर उस यूज़र के लिए है जो ServBay को ओरिजिन सर्वर बनाना चाहता है: पहले डिफ़ॉल्ट व्यवहार समझाएँगे, फिर "बिल्ट-इन टनल → रिवर्स प्रॉक्सी (सुझावित) → पोर्ट फॉरवर्डिंग" के क्रम में संपूर्ण समाधान बताएँगे, और अंत में एक जनरल ट्रबलशूटिंग चेकलिस्ट देंगे।

अनुकूल प्लेटफ़ॉर्म

यह गाइड ServBay for macOS और ServBay for Windows दोनों प्लेटफॉर्म पर लागू है। दोनों पर वेबसाइट का प्रोटोकॉल, लिसन बिहेवियर और सर्टिफिकेट पाथ एक-सा है, बस इंस्टाल डाइरेक्टरी अलग है (macOS में /Applications/ServBay, Windows में आम तौर पर C:\ServBay)। डिफ़ॉल्ट वेब सर्वर थोड़ा अलग है: macOS में डिफ़ॉल्ट Caddy, Windows में डिफ़ॉल्ट Nginx—दोनों में Nginx / Apache / Caddy स्विच किया जा सकता है।

पहले समझें ServBay का डिफ़ॉल्ट नेटवर्क व्यवहार

अधिकतर पब्लिक एक्सेस समस्याएँ निम्नलिखित डिफॉल्ट व्यवहार के गलतफहमी से होती हैं:

1. वेबसाइट डिफॉल्ट प्रोटोकॉल है HTTP & HTTPS। इस मोड में HTTP (80) पर एक्सेस को हमेशा के लिए 301 रीडायरेक्ट कर दिया जाता है HTTPS (443) पर। यह आज के दौर के अनुरूप डिफ़ॉल्ट है—आपको HTTPS ही चुनना चाहिए, न कि अस्पष्ट 80 पोर्ट।
2. HTTPS SNI (Server Name Indication) से साइट और सर्टिफिकेट चुनता है। एक ही ServBay ओएस पर कई वेबसाइट्स TLS हैंडशेक के SNI (यानी डोमेन) से मैच होती हैं। रिवर्स प्रॉक्सी जब HTTPS बैक टू ओरिजिन करता है तो सही SNI भेजना अनिवार्य है, नहीं तो डिफॉल्ट साइट/सर्टिफिकेट मिलेगा।
3. डिफॉल्ट रूप से सभी नेटवर्क इंटरफेस (0.0.0.0) पर लिसन करता है, डिफॉल्ट पोर्ट HTTP 80 / HTTPS 443 होते हैं, जिससे बाहरी एक्सेस अनुमति मिली रहती है, सामान्यत: बाइंडिंग पता बदलने की आवश्यकता नहीं।
4. लोकल HTTPS सर्टिफिकेट ServBay CA द्वारा साइन किए जाते हैं। ServBay में एक इंटीग्रेटेड लोकल CA (ServBay User CA - ECC Root) होता है, जो वेबसाइट्स के लिए सर्टिफिकेट जारी करता है। ब्राउज़र पब्लिक नेटवर्क पर इसे ट्रस्ट नहीं करते—लेकिन रिवर्स प्रॉक्सी साइड पर इसे ट्रस्ट कर लें (या वेरिफिकेशन स्किप करें), बैक-टू-ओरिजिन के लिए पब्लिक CA की ज़रूरत नहीं पड़ेगी।

आम गलतफहमी: HTTP & HTTPS + केवल 80 फॉरवर्ड करना

अगर वेबसाइट डिफॉल्ट HTTP & HTTPS पर है, और आपने सिर्फ 80 फॉरवर्ड किया, 443 को नहीं छुआ: क्लाइंट http://डोमेन मांगेगा → ServBay 301 देगा https://डोमेन पर → क्लाइंट 443 पोर्ट से कनेक्ट करेगा → उत्तर नहीं मिलेगा → कनेक्शन फेल। ब्राउज़र और HSTS इस 301 को कैश कर सकते हैं, जिससे समस्या डिबग करना और कठिन हो जाता है।

सही रास्ता HTTPS को काम में लेना है (नीचे रिवर्स प्रॉक्सी देखें), पिछला HTTP 80 नहीं लौटना।

तीन पब्लिशिंग तरीकों में से चयन कैसे करें

तरीका	विवरण	उपयुक्त उपयोग
बिल्ट-इन टनल (frpc/cloudflared आदि)	ServBay में तैयार, बाहर टनल बनाती है, न पब्लिक IP चाहिए, न पोर्ट ओपन	जिनके पास पब्लिक IP नहीं, होम/NAT नेटवर्क, या फास्ट एक्सेस चाहिए
फ्रंट रिवर्स प्रॉक्सी (सुझावित)	Nginx/HAProxy/Caddy/Traefik पब्लिक ट्रैफिक लेता है, सर्टिफिकेट संभालता है, फिर HTTPS बैक टू ओरिजिन करता है	पब्लिक एंट्रीपॉइंट है, सेंट्रल सर्टिफिकेट/मल्टी बैकएंड चाहिए
पोर्ट फॉरवर्डिंग (NAT)	गेटवे पब्लिक पोर्ट सीधे ServBay होस्ट को फॉरवर्ड करता है	एक ही बैकएंड हो, और कंफ्यूजन न हो

तरीका 1: बिल्ट-इन टनल (सबसे आसान, पब्लिक IP की ज़रूरत नहीं)

अगर आपके पास पब्लिक IP नहीं है या रिवर्स प्रॉक्सी/सर्टिफिकेट्स का झंझट नहीं चाहिए, ServBay का बिल्ट-इन टनल सबसे आसान विकल्प है। ये ServBay से बतौर आउटबाउंड कनेक्शन बिठाते हैं, NAT, IPv6, पोर्ट फॉरवर्डिंग, सर्टिफिकेट ट्रस्ट सभी दिक्कतें अपने-आप हल हो जाती हैं:

• Cloudflare Tunnel (cloudflared) — Cloudflare ग्लोबल नेटवर्क से लोकल साइट को पब्लिक करती है, ऑटोमेटिकली पब्लिक ट्रस्टेड HTTPS मिलता है, कोई पोर्ट ओपन नहीं करना। बढ़िया अगर पब्लिक डोमेन+CDN/WAF चाहिए।
• frp (frpc) — अपने-आप के frps सर्वर से कनेक्ट कर सकते हैं, पूरी तरह स्वयं कंट्रोल में।
• ngrok / Pinggy — तुरंत टेम्पररी पब्लिक URL जेनरेट करते हैं, डेमो या वेबहुक टेस्टिंग के लिए सही।

अधिकतर यूज़र्स के लिए cloudflared टनल बना कर "लोकल साइट को पब्लिक करना" भरपूर है, आगे रिवर्स प्रॉक्सी/पोर्ट फॉरवर्डिंग की ज़रूरत नहीं पड़ेगी।

तरीका 2: फ्रंट रिवर्स प्रॉक्सी + HTTPS बैक टू ओरिजिन (सुझावित)

यह प्रोडक्शन के लिए सबसे अच्छा तरीका है: रिवर्स प्रॉक्सी पब्लिक सर्टिफिकेट के साथ HTTPS सर्व करता है, और ओरिजिन सर्वर—यानी ServBay—पर भी HTTPS यूज़ करता है (HTTP & HTTPS मोड बना रहता है), जिससे पूरी चेन में एन्क्रिप्शन रहता है।

HTTPS बैक टू ओरिजिन ही क्यों, सिर्फ HTTP 80 क्यों नहीं?

इंटरनेट की ज़्यादातर गाइड्स आज भी "बैकएंड HTTP चलाओ, प्रॉक्सी से प्लेन टेक्स्ट में बैक टू ओरिजिन" वाली पुरानी थीम पर अटकी हैं। हम ये तरीका नहीं सुझाते, अगर बहुत जरुरी वजह न हो:

• एंड-टू-एंड एन्क्रिप्शन: चाहे प्रॉक्सी और ServBay दोनों प्राइवेट नेटवर्क में हों, ट्रैफिक पूरा रास्ता एन्क्रिप्टेड रहता है जिससे नेटवर्क स्निफिंग और बीच में मॉडिफिकेशन नहीं हो सकता।
• आधुनिक प्रोटोकॉल सपोर्ट: HTTPS चालू रहेगा तभी प्रॉक्सी HTTP/2 (h2) इनेबल कर सकता है, जिससे मल्टीप्लेक्सिंग, हेडर कंप्रेशन, कनेक्शन री-यूज़ आदि मिलते हैं; प्लेन HTTP 80 में ये संभव नहीं।
• अपग्रेड से डेसग्रेडेशन की समस्याएँ: एक बार HTTP पर लौटे तो HTTP & HTTPS के 301, HSTS कैश, एप्लिकेशन लेयर की https लिंक जेनरेशन जैसी परेशानियों से जूझना पड़ता है।
• ServBay CA को ट्रस्ट करना सरल है: ServBay का सेल्फ़-साइन CA प्रॉब्लम नहीं है—रिवर्स प्रॉक्सी पर इसे ट्रस्ट कर लें या वेरिफिकेशन स्किप कर दें, एक बार सेट करें लंबे समय चलेगा।

प्लेन HTTP 80 के लिए तीसरा तरीका देखें, केवल उन्हीं के लिए जो साइड-इफेक्ट पूरी तरह समझते हैं।

कॉमन की पॉइंट्स

निम्नलिखित सभी रिवर्स प्रॉक्सी पर लागू होते हैं, उदाहरण में: पब्लिक डोमेन example.com, ServBay बैकएंड 192.168.1.115, बैकएंड HTTPS पोर्ट 443, और वेबसाइट HTTP & HTTPS मोड पर है।

1. HTTPS बैक टू ओरिजिन: रिवर्स प्रॉक्सी का proxy_pass या अपस्ट्रीम https://192.168.1.115:443 होना चाहिए।
2. सही SNI भेजें: SNI बिल्कुल वही होनी चाहिए जो ServBay में साइट का डोमेन है (example.com)।
3. ServBay CA को ट्रस्ट करें (सुझावित) या वेरिफाइ स्किप करें: आगे CA फाइल लाने की विधि देखें।
4. Host हेडर ट्रांसपैरेंट पास करें: Host: example.com, ताकि ServBay का server_name मैच करे।
5. X-Forwarded-Proto: https भेजें: जिससे बैकएंड एप्लिकेशन जान सके कि ओरिजिनल रिक्वेस्ट https थी, गलत रीडायरेक्ट्स या लिंक जेनरेटिंग से बचाव।
6. IPv4 / IPv6 एकरूपता: IPv4/IPv6 एकरूपता देखें।

ServBay CA कैसे प्राप्त करें (रिवर्स प्रॉक्सी के लिए)

ServBay का लोकल CA सर्टिफिकेट इंस्टाल लोकेशन में पाया जा सकता है:

• macOS: /Applications/ServBay/ssl/private/ServBay-Private-CA-ECC-Root.crt
• Windows: C:\ServBay\ssl\private\ServBay-Private-CA-ECC-Root.crt

इस .crt फाइल को रिवर्स प्रॉक्सी सर्वर (जैसे /etc/nginx/servbay-ca/) में कॉपी करें और प्रॉक्सी सेटिंग में इसे ट्रस्टेड CA की तरह यूज़ करें।

सर्टिफिकेट चेन के बारे में

ServBay में "रूट CA + इंटरमीडियेट CA" स्ट्रक्चर है, साइट सर्टिफिकेट इंटरमीडियेट से साइन होता है। अगर प्रॉक्सी केवल रूट सर्टिफिकेट से वेरिफिकेशन फेल दे, तो रूट और इंटरमीडियेट दोनों फाइल्स (जैसे ServBay-Private-CA-ECC-Intermediate.crt) को मर्ज करके CA बंडल बनाएं; या पहले "वेरिफिकेशन स्किप" करें, फिर बाद में स्ट्रिक्ट मोड चुनें।

Nginx रिवर्स प्रॉक्सी (HTTPS बैक टू ओरिजिन)

server {
    listen 443 ssl;
    listen [::]:443 ssl;                 # IPv6 सपोर्ट चाहिए तो
    server_name example.com;

    # पब्लिक के लिए ट्रस्टेड सर्टिफिकेट (जैसे Let's Encrypt)
    ssl_certificate     /etc/nginx/certs/example.com/fullchain.pem;
    ssl_certificate_key /etc/nginx/certs/example.com/privkey.pem;

    location / {
        proxy_pass https://192.168.1.115:443;                 # HTTPS बैक टू ओरिजिन

        # —— जरूरी: SNI और वेरिफिकेशन ——
        proxy_ssl_server_name on;                             # SNI भेजें
        proxy_ssl_name        example.com;                    # SNI = ServBay साइट डोमेन
        proxy_ssl_trusted_certificate /etc/nginx/servbay-ca/servbay-ca-bundle.crt;
        proxy_ssl_verify      on;                             # ServBay CA ट्रस्ट कर वेरिफाइ ऑन करें
        proxy_ssl_verify_depth 2;                             # रूट + इंटरमीडियेट लेवल
        # सिंपल तरीका (CA नहीं कॉन्फ़िगर): proxy_ssl_verify off;

        # —— जरूरी: Host और प्रोटोकॉल फॉरवर्ड करें ——
        proxy_set_header Host              $host;
        proxy_set_header X-Real-IP         $remote_addr;
        proxy_set_header X-Forwarded-For   $proxy_add_x_forwarded_for;
        proxy_set_header X-Forwarded-Proto $scheme;
    }
}

# HTTP से HTTPS का रीडायरेक्ट प्रॉक्सी में ही करें
server {
    listen 80;
    listen [::]:80;
    server_name example.com;
    return 301 https://$host$request_uri;
}

HAProxy रिवर्स प्रॉक्सी (HTTPS बैक टू ओरिजिन)

frontend fe_web
    bind :80
    bind :443 ssl crt /etc/haproxy/certs/example.com.pem
    http-request redirect scheme https unless { ssl_fc }
    http-request set-header X-Forwarded-Proto https if { ssl_fc }
    default_backend be_servbay

backend be_servbay
    option forwardfor
    http-request set-header Host example.com
    # HTTPS बैक टू ओरिजिन: ssl + SNI भेजें + ServBay CA वेरीफाई करें
    server servbay1 192.168.1.115:443 ssl sni str(example.com) \
        verify required ca-file /etc/haproxy/servbay-ca/servbay-ca-bundle.crt
    # सिंपल तरीका: server servbay1 192.168.1.115:443 ssl sni str(example.com) verify none

Caddy रिवर्स प्रॉक्सी (HTTPS बैक टू ओरिजिन)

Caddy अपने-आप example.com के लिए पब्लिक सर्टिफिकेट्स जारी और री-न्यू करता है, reverse_proxy डिफॉ़ल्ट में Host,X-Forwarded-* फॉरवर्ड करता है:

example.com {
    reverse_proxy https://192.168.1.115:443 {
        header_up Host {host}
        transport http {
            tls_server_name example.com                                  # SNI
            tls_trusted_ca_certs /etc/caddy/servbay-ca/servbay-ca-bundle.crt
            # सिंपल तरीका: tls_insecure_skip_verify
        }
    }
}

Traefik रिवर्स प्रॉक्सी (HTTPS बैक टू ओरिजिन)

फाइल प्रोवाइडर के साथ डायनामिक सेटिंग का उदाहरण:

# traefik-dynamic.yml
http:
  routers:
    servbay:
      rule: "Host(`example.com`)"
      entryPoints:
        - websecure
      service: servbay
      tls:
        certResolver: letsencrypt
  services:
    servbay:
      loadBalancer:
        passHostHeader: true                 # Host फॉरवर्ड करें
        servers:
          - url: "https://192.168.1.115:443" # HTTPS बैक टू ओरिजिन
        serversTransport: servbay-tls

serversTransports:
  servbay-tls:
    serverName: example.com                  # SNI
    rootCAs:
      - /etc/traefik/servbay-ca/servbay-ca-bundle.crt
    # सिंपल तरीका: insecureSkipVerify: true

तरीका 3: पोर्ट फॉरवर्डिंग (NAT)

अगर आपके पास केवल एक बैकएंड है, तो गेटवे/राउटर पर पब्लिक पोर्ट्स को सीधे ServBay होस्ट (उदा. 192.168.1.115) को फॉरवर्ड कर सकते हैं।

सुझावित: 443/HTTPS फॉरवर्ड करें

1. राउटर पोर्ट फॉरवर्डिंग: पब्लिक 443 → 192.168.1.115:443 (साथ ही पब्लिक 80 → 192.168.1.115:80, जिससे ServBay खुद 80 से 443 भेज देगा)।
2. DNS में A रिकॉर्ड पब्लिक IPv4 को पॉइंट करे।
3. साइट का मोड HTTP & HTTPS रखें। चूंकि पब्लिक क्लाइंट्स सीधे ServBay से कनेक्ट करेंगे, इस डोमेन के लिए पब्लिक ट्रस्टेड सर्टिफिकेट चाहिए और कॉन्फिगर करना होगा, नहीं तो ब्राउजर सर्टिफिकेट वॉर्निंग देगा।
4. सुनिश्चित करें IPv4/IPv6 एकरूपता है (नीचे देखें)।

केवल HTTP 80 फॉरवर्ड करें (केवल विशेष मौके पर)

केवल 80 फॉरवर्ड और वेबसाइट को HTTP मोड पर सेट करने से HTTPS और HTTP/2 का फायदा नहीं मिलेगा और ब्राउज़र HSTS या कैश के साथ टकराव हो सकता है। केवल तब करें जब आपको इसके साइड-इफेक्ट पूरी तरह पता हों। अगर जरूर हो: साइट प्रोटोकॉल साफ़-साफ़ HTTP चुनें (301 से अनावश्यक 443 की ओर रीडायरेक्ट न हो), और केवल 80 फॉरवर्ड करें।

IPv4 / IPv6 एकरूपता

पब्लिक एक्सेस की अस्थिरता का एक आम कारण। अगर डोमेन में A (IPv4) और AAAA (IPv6) रिकॉर्ड दोनों हैं, तो क्लाइंट Happy Eyeballs एल्गोरिद्म के कारण कभी कभी IPv6 पहले यूज़ करेगा; अगर आपने केवल IPv4 के लिए फॉरवर्ड/प्रॉक्सी किया, तो IPv6 की रिक्वेस्ट्स फेल जाएंगी। दो विकल्प:

• केवल IPv4 यूज़ करें: सुनिश्चित करें dig AAAA आपकी-डोमेन +short खाली है, बस A रिकॉर्ड रखें।
• दोनों सपोर्ट करें: IPv6 के लिए भी फॉरवर्डिंग, प्रॉक्सी लेवल पर [::] लिसन, और बैकएंड पर भी IPv6 का रास्ता पुष्टि करें।

एक्सेस एरर ट्रबलशूटिंग चेकलिस्ट

पब्लिक एक्सेस की समस्या (नहीं खुल रही, टोटली टाइमआउट, सर्टिफिकेट एरर, रॉंग साइट आदि) हो तो क्रमवार जाँचें (डोमेन example.com, बैकएंड 192.168.1.115):

1. कहीं 301 रीडायरेक्ट तो 443 की ओर?

   curl -I http://example.com

   अगर 301 लौटे और Location: https://... दिखे, लेकिन आपने 443 नहीं हैंडल किया है → यहीं दिक्कत। HTTPS सक्षम करें (सुझावित) या साइट को HTTP मोड में सेट करें।

2. कहीं IPv6 गड़बड़ कर रहा है?

   curl -4 -I https://example.com     # केवल IPv4
   curl -6 -I https://example.com     # केवल IPv6
   dig A example.com +short
   dig AAAA example.com +short        # AAAA तो है पर IPv6 काम नहीं कर रहा → हटाएँ या Configure करें

3. बैक टू ओरिजिन का SNI/सर्टिफिकेट तो सही है? (HTTPS बैक टू ओरिजिन के सीन में) डायरेक्ट सर्वर को SNI के साथ हिट करें:

   curl -I --resolve example.com:443:192.168.1.115 https://example.com \
        --cacert /path/servbay-ca-bundle.crt

   अगर सर्टिफिकेट/साइट मिसमैच मिले, तो SNI या CA ट्रस्ट न होने की समस्या।

4. रिक्वेस्ट ServBay तक पहुँची भी या नहीं? ServBay होस्ट में लॉग देखें ("View Log Files")। टाइमआउट रिक्वेस्ट्स अगर लॉग में नहीं है, तो नेटवर्क/गेटवे/प्रॉक्सी में अटकी है।

5. Host हेडर तो ठीक है? (L7 रिवर्स प्रॉक्सी सीन)

   curl -k -I -H "Host: example.com" https://192.168.1.115/

   डायरेक्ट बैकएंड पर सही, लेकिन प्रॉक्सी पर गलत → Host हेडर प्रॉक्सी में फॉरवर्ड नहीं हुआ।

सर्टिफिकेट एवं सिक्योरिटी

• बैक टू ओरिजिन लिंक: जब रिवर्स प्रॉक्सी → ServBay HTTPS चल रहा है, बस प्रॉक्सी में ServBay CA (ServBay-Private-CA-ECC-Root.crt, जरुरत पडे़ तो इंटरमीडिएट भी) ट्रस्ट कर दें; ये इन-हाउस ट्रस्ट है, एक बार सेट अप लंबे समय के लिए।
• एक्सटर्नल सर्टिफिकेट: पब्लिक क्लाइंट के लिए सर्टिफिकेट पब्लिक ट्रस्टेड ही हो; रिवर्स प्रॉक्सी केस में प्रॉक्सी मैनेज करता है (Caddy/Traefik ऑटोमेटिकली सर्टिफिकेट जारी कर सकते हैं); पोर्ट फॉरवर्डिंग में सीधे ServBay पर वह डोमेन का पब्लिक सर्टिफिकेट सेट करें, ACME से सर्टिफिकेट लेने के तरीके देखें। ServBay के ServBay User CA द्वारा दिए सर्टिफिकेट सिर्फ लोकल/LAN के लिए ठीक हैं, पब्लिक यूज़र्स ट्रस्ट नहीं करेंगे।
• डेटाबेस कभी पब्लिक न करें: वेबसाइट को पब्लिक करते हुए कभी MySQL, Redis, Memcached आदि के पोर्ट भी एक्सपोज न करें। और जानकारी लोकल नेटवर्क एक्सेस के सिक्योरिटी सेक्शन में।
• फायरवॉल: केवल आवश्यक पोर्ट खोलें, बाकी सब ब्लॉक रखें।

अक्सर पूछे जाने वाले प्रश्न (FAQ)

• Q: लोकल में वेबसाइट सही, लेकिन पब्लिक पर गड़बड़ — क्या DNS इश्यू है?
  • A: ज़्यादातर बार नहीं। 301 HTTPS रीडायरेक्ट, SNI/सर्टिफिकेट का मिसमैच, Host हेडर ट्रांसपेरेंसी न होना या IPv4/IPv6 मिसमैच आम वजहें हैं। ऊपर दी हुई चेकलिस्ट से एक-एक चेक करें।
• Q: क्या केवल HTTP 80 से ही रिवर्स प्रॉक्सी संभव है?
  • A: नहीं, और सलाह भी नहीं दी जाती। HTTP & HTTPS बनाए रखें, रिवर्स प्रॉक्सी से HTTPS बैक टू ओरिजिन करें और ServBay CA ट्रस्ट करें (या वेरिफाइ स्किप करें), इससे सिक्योरिटी और HTTP/2 दोनों मिलेगा।
• Q: रिवर्स प्रॉक्सी में सर्टिफिकेट एरर या गलत साइट दिख रही?
  • A: सही SNI (यानी साइट डोमेन) भेजें, ServBay CA (जरुरत हो तो इंटरमीडिएट के साथ) ट्रस्ट करें। फौरन टेस्ट के लिए पहले वेरिफिकेशन स्किप करें, बाद में स्ट्रिक्ट करें।
• Q: क्या ServBay को प्रोडक्शन में ओरिजिन सर्वर बनाना स्थिर है?
  • A: बिल्कुल। ढेर सारे यूज़र्स Mac mini / Windows सर्वर को IDC में होस्ट करके सर्विस देते हैं। जरूरी है प्रोटोकॉल मोड, SNI, Host हेडर, सर्टिफिकेट ट्रस्ट और IPv4/IPv6 सिंक में होना।
• Q: मेरे पास पब्लिक IP नहीं तो?
  • A: तरीका 1: बिल्ट-इन टनल (cloudflared / frpc) यूज़ करें—ना पब्लिक IP चाहिए, न पोर्ट फॉरवर्डिंग।

सारांश

ServBay को ओरिजिन सर्वर बनाकर पब्लिक में प्रकाशित करना तकनीकी रूप से बिलकुल संभव है। सुझावित तरीका है: वेबसाइट का HTTP & HTTPS मोड रखें, फ्रंट-एंड रिवर्स प्रॉक्सी से HTTPS बैक टू ओरिजिन करें, सही SNI भेजें और ServBay CA ट्रस्ट करें—इससे एंड-टू-एंड एन्क्रिप्शन और HTTP/2 जैसी आधुनिक तकनीकें मिलती हैं। अगर पब्लिक IP नहीं है, तो इंटरनल cloudflared / frpc टनल बेस्ट है; पोर्ट फॉरवर्डिंग सिर्फ उन्हीं के लिए है, जिन्हें तकनीकी बातें पूरी तरह समझ में हैं। पब्लिक एक्सेस में दिक्कत हो, तो ऊपर दी चेकलिस्ट से डिबग करें—अधिकतर प्रॉब्लम प्रोटोकॉल मोड, SNI/सर्टिफिकेट, Host हेडर या IPv4/IPv6 से ही जुड़ी होती हैं।