dsh web http://127.0.0.1:3080 का क्या अर्थ है

dsh web: http://127.0.0.1:3080 का क्या अर्थ है

जब आप VPS पर DeepSeek Harness वेब प्रोफाइल शुरू करते हैं, तो यह दो लाइनें प्रिंट करता है और फिर प्रतीक्षा करता है:

dsh web: http://127.0.0.1:3080
Ready.

127.0.0.1 लूपबैक एड्रेस है। यह वह एड्रेस है जिसका उपयोग एक मशीन खुद से बात करने के लिए करती है। 127.0.0.1 पर बाइंड किया गया सॉकेट केवल उसी मशीन की प्रक्रियाओं से कनेक्शन स्वीकार करता है, और कहीं से नहीं। इसलिए वह लाइन आपको एक साथ दो बातें बताती है: वेब UI कहाँ लिसन कर रहा है, और इसे एक्सेस करने की अनुमति किसे है। केवल वह मशीन जिस पर dsh चल रहा है।

यही कारण है कि जब आप अपने लैपटॉप के ब्राउज़र में URL पेस्ट करते हैं तो कुछ नहीं होता है। आपके लैपटॉप का 127.0.0.1 आपका लैपटॉप ही है। हार्नेस VPS के 127.0.0.1 पर लिसन कर रहा है, जो एक अलग मशीन है और जिसका लूपबैक स्टैक भी अलग है। कुछ भी खराब नहीं है। आपको कनेक्शन को आगे ले जाने (carry) की आवश्यकता है।

आधिकारिक README डिफ़ॉल्ट को स्पष्ट रूप से बताता है: "यह कमांड वेब UI शुरू करती है, जो डिफ़ॉल्ट रूप से http://127.0.0.1:3080 पर सर्व होता है।" बाइंड एड्रेस वेबसर्वर होस्ट प्लगइन, @deepseek-ai/dsh-host-webserver से आता है, जिसकी host की को "Listen host; the two supported values are loopback and all-interfaces" के रूप में प्रलेखित किया गया है। जब तक आप इसे बदलते नहीं हैं, तब तक आपको लूपबैक ही मिलता है। यदि पोर्ट्स आपके लिए नए हैं, तो Linux पर पोर्ट्स कैसे काम करते हैं उस एड्रेस-प्लस-पोर्ट मॉडल को कवर करता है जिस पर यह सब आधारित है।

Web UI केवल localhost पर bind क्यों होता है

dsh एक agent harness है, जो model के चारों ओर लपेटा गया प्रोग्राम है: यह लूप, टूल कॉल्स और उन अनुमतियों को नियंत्रित करता है जिनके तहत ये कॉल्स चलते हैं। ब्राउज़र टैब उस प्रक्रिया के लिए एक कंट्रोल सरफेस है जो शेल कमांड चलाती है, आपके द्वारा चुनी गई वर्कस्पेस डायरेक्टरी में फाइलें पढ़ती और लिखती है, और आपकी model API key का उपयोग करती है। जो कोई भी उस पेज को लोड कर सकता है, वह dsh चलाने वाले उपयोगकर्ता के रूप में यह सब कर सकता है। नेटवर्क ही इस पहुंच का एकमात्र जरिया नहीं है: आपके द्वारा इंस्टॉल किया गया कोई प्लगइन उसी प्रक्रिया के भीतर समान अनुमतियों के साथ चलता है, यही कारण है कि dsh प्लगइन को इंस्टॉल करने से पहले उसकी जांच करना उतना ही महत्वपूर्ण है जितना यह तय करना कि सर्वर किस पोर्ट पर listen करेगा।

इसलिए पोर्ट 3080 केवल एक read-only डैशबोर्ड नहीं है। उस पेज को लोड करने का मतलब है सर्वर पर कमांड निष्पादित (execute) करने की क्षमता प्राप्त करना।

Web UI खोलते ही आप सीधे सेशन लिस्ट में पहुंच जाते हैं। इसमें कोई लॉगिन प्रॉम्प्ट नहीं है, क्योंकि डेवलपर प्रीव्यू में कोई यूजर अकाउंट और रिमोट ऑथेंटिकेशन नहीं दिया गया है। लूपबैक पर यह सुसंगत है: ऑपरेटिंग सिस्टम ही एक्सेस कंट्रोल है, और केवल स्थानीय प्रक्रियाएं ही वहां तक पहुंच सकती हैं। यदि आप उसी सर्वर को पब्लिक IP वाले VPS पर 0.0.0.0 पर bind करते हैं, तो वही पेज पूरे इंटरनेट के लिए खुल जाता है, और उसके आगे कोई सुरक्षा नहीं होती। ऑटोमेटेड स्कैनर्स लगातार असामान्य पोर्ट्स को स्कैन करते रहते हैं, इसलिए एक पब्लिश किए गए 3080 पोर्ट को 'खोजा हुआ' ही मानें।

अपने फायरवॉल में पोर्ट 3080 न खोलें, और पब्लिक VPS पर वेबसर्वर host को 0.0.0.0 पर सेट न करें। यह संयोजन आपके सर्वर पर कमांड निष्पादित करने की शक्ति किसी भी ऐसे व्यक्ति को दे देता है जो सबसे पहले कनेक्ट करता है।

यही तर्क हर उस एजेंट रनटाइम पर लागू होता है जिसे आप सर्वर पर डालते हैं, और इसीलिए VPS पर कोडिंग एजेंट को सुरक्षित रूप से चलाना इसी नियम से शुरू होता है: एजेंट का कंट्रोल पोर्ट निजी रहना चाहिए, और आप तक पहुंचने के लिए किसी विश्वसनीय माध्यम का उपयोग किया जाना चाहिए।

मैं अपने लैपटॉप से dsh Web UI कैसे खोलूँ?

इसके तीन सही तरीके हैं, और इनमें से हर एक harness को loopback पर ही bound रखता है।

• एक SSH tunnel। सार्वजनिक interface पर कोई नई चीज़ listen नहीं करती है, और आपके पास पहले से ही credentials मौजूद हैं। यही वह तरीका है जिसका उपयोग करना चाहिए।
• एक private overlay network, ताकि UI आपके अपने उपकरणों से तो पहुँच योग्य हो, लेकिन बाकी किसी के लिए अदृश्य रहे।
• एक reverse proxy जो TLS (transport layer security) को terminate करता है और किसी भी चीज़ को forward करने से पहले पासवर्ड मांगता है।

इनके बीच का अंतर यह है कि आपके ब्राउज़र को loopback तक कौन ले जाता है। इनमें से किसी में भी harness को loopback से हटाना शामिल नहीं होना चाहिए।

SSH tunnel के माध्यम से इसे एक्सेस करें

इसे अपने laptop पर चलाएं, VPS पर नहीं:

ssh -N -L 3080:127.0.0.1:3080 you@your-vps

इसे चलते रहने दें, फिर अपने local browser में http://127.0.0.1:3080 खोलें। Web UI लोड हो जाएगा।

-L argument में कोलन (colons) द्वारा अलग किए गए तीन fields होते हैं। पहला field आपके laptop पर खुलने वाला port है। दूसरा और तीसरा field वह address और port है जहाँ connection को forward करना है। ध्यान देने वाली बात यह है: middle field में मौजूद 127.0.0.1 को VPS पर स्थित SSH server द्वारा resolve किया जाता है, जब आपका traffic वहाँ पहुँच चुका होता है। इसका अर्थ है VPS का loopback, न कि आपका। यही वह address है जिसे dsh ने print किया था, और इसीलिए tunnel काम करता है जबकि सीधा browser connection काम नहीं करता।

-N SSH को remote command न चलाने का निर्देश देता है, जिससे आपको केवल एक forwarder मिलता है, shell नहीं। एक ऐसे background tunnel के लिए जो चुपचाप फेल होने के बजाय स्पष्ट रूप से error दिखाए:

ssh -N -f -o ExitOnForwardFailure=yes -o ServerAliveInterval=30 -L 3080:127.0.0.1:3080 you@your-vps

-f authentication के बाद इसे background में डाल देता है। ExitOnForwardFailure=yes का महत्व दिखने से कहीं अधिक है: इसके बिना, SSH तब भी सफलतापूर्वक connect हो जाता है जब forward setup न हो पाया हो, जिससे आपको एक working session तो मिलता है लेकिन बिना किसी चेतावनी के एक dead tunnel हाथ लगता है। ServerAliveInterval=30 हर 30 seconds में एक keepalive भेजता है ताकि idle tunnel कैफे और होटल के routers पर NAT (network address translation) timeouts के बावजूद बना रहे।

आपको क्या दिखाई देना चाहिए

VPS पर, पुष्टि करें कि वास्तव में कौन सा port listening स्थिति में है:

ss -ltnp | grep 3080

एक सही परिणाम loopback address को दर्शाता है:

LISTEN 0  511  127.0.0.1:3080  0.0.0.0:*  users:(("node",pid=1042,fd=21))

यदि local address column में 0.0.0.0:3080 दिखाई दे, तो Web UI हर interface पर उपलब्ध है, जिसमें public interface भी शामिल है। इसे रोकें और कुछ भी करने से पहले bind को ठीक करें। यदि ss socket को तो दिखाता है लेकिन users: field खाली रहता है, तो इसे sudo के साथ चलाएं, क्योंकि अन्यथा किसी अन्य user के स्वामित्व वाले socket का process name छिपा रहता है।

जब tunnel start होने से मना कर दे

SSH यह print करके exit हो जाता है:

bind [127.0.0.1]:3080: Address already in use
channel_setup_fwd_listener_tcpip: cannot listen to port: 3080

यह आपके laptop से संबंधित है, server से नहीं। किसी local process ने पहले ही port 3080 को रोक रखा है, अक्सर यह कोई पुराना tunnel होता है जिसे आप भूल गए हैं। इसके बजाय कोई free local port चुनें:

ssh -N -L 3081:127.0.0.1:3080 you@your-vps

केवल पहला field बदला गया है, इसलिए अब आप http://127.0.0.1:3081 पर browse करें जबकि harness 3080 पर listening जारी रखेगा। दोनों numbers का आपस में मेल खाना जरूरी नहीं है।

यदि tunnel start हो जाता है लेकिन browser connection refused या empty reply की रिपोर्ट देता है, तो traffic VPS तक तो पहुँचा लेकिन दूसरी तरफ उसे कुछ नहीं मिला। या तो dsh बंद हो चुका है, या उसने किसी अलग port पर bind किया है। server पर ss -ltnp | grep 3080 के साथ जाँच करें।

एक और बात जो अक्सर लोगों को परेशान करती है। एक foreground npx @deepseek-ai/dsh web तब बंद हो जाता है जब उसका shell बंद होता है, इसलिए जैसे ही आप logout करते हैं, harness रुक जाता है। इसे tmux के अंदर या systemd user service के तहत start करें, जो कि VPS पर coding agent को चालू रखने में हल की गई समस्या के समान है। जब आप SSH side पर काम कर रहे हों, तो अपने VPS पर SSH को सुरक्षित करना पहले कर लेना उचित है, क्योंकि tunnel आपके SSH login को agent तक पहुँचने का एकमात्र द्वार बना देता है।

इसे एक private overlay network के माध्यम से एक्सेस करें

एक overlay network आपके VPS और आपके laptop को एक ऐसे private network पर address देता है जिससे केवल आपके उपकरण जुड़ते हैं। Tailscale एक सामान्य विकल्प है, और इसका serve command इस स्थिति के लिए बिल्कुल उपयुक्त है: tailscaled VPS पर चलता है और खुद को localhost:3080 से जोड़ता है, इसलिए harness loopback पर ही रहता है और आपको dsh के configuration में कुछ भी बदलने की आवश्यकता नहीं होती।

tailscale serve --bg localhost:3080
tailscale serve status

इसके बाद UI आपके tailnet के भीतर आपकी machine के नाम पर, HTTPS के माध्यम से, बिना किसी public interface पर port खोले एक्सेस किया जा सकता है। इसके लिए आपके tailnet पर HTTPS certificates का enabled होना आवश्यक है, अन्यथा serve के पास प्रस्तुत करने के लिए कोई certificate नहीं होगा। इसे वापस हटाने के लिए, off के साथ command को दोहराएं:

tailscale serve --https=443 off

serve का उपयोग करें, funnel का कभी नहीं। Funnel उसी target को public internet पर प्रकाशित कर देता है, जिससे आप वापस एक open port पर unauthenticated agent runtime की स्थिति में आ जाते हैं। ये दोनों commands लगभग एक जैसे दिखते हैं और विपरीत कार्य करते हैं, इसलिए किसी को भी टाइप करने से पहले Tailscale Serve और Funnel के बीच का अंतर पढ़ें। Tailscale एक private network के रूप में setup की प्रक्रिया को कवर करता है।

इसे ऐसे reverse proxy के माध्यम से एक्सेस करें जो पासवर्ड की जाँच करता है

यह वह विकल्प है जो वास्तव में एक port को इंटरनेट पर प्रकाशित करता है, इसलिए आपके सर्वर पर किसी अजनबी द्वारा command execution के बीच केवल authentication ही एकमात्र बाधा है। इसे तब चुनें जब कई लोगों को UI की आवश्यकता हो और प्रत्येक के लिए tunnel बनाना अव्यावहारिक हो।

Harness 127.0.0.1:3080 पर चलता है। nginx उसी box पर चलता है, इसलिए यह loopback तक पहुँच सकता है, और यह एक certificate तथा पासवर्ड फ़ाइल के साथ 443 पर listen करता है।

server {
    listen 443 ssl;
    server_name dsh.example.com;

    ssl_certificate     /etc/letsencrypt/live/dsh.example.com/fullchain.pem;
    ssl_certificate_key /etc/letsencrypt/live/dsh.example.com/privkey.pem;

    auth_basic           "dsh";
    auth_basic_user_file /etc/nginx/dsh.htpasswd;

    location / {
        proxy_pass http://127.0.0.1:3080;
        proxy_http_version 1.1;
        proxy_set_header Upgrade $http_upgrade;
        proxy_set_header Connection "upgrade";
        proxy_set_header Host $host;
        proxy_read_timeout 3600s;
        proxy_buffering off;
    }
}

पासवर्ड फ़ाइल बनाएँ और reload करें:

sudo apt install -y apache2-utils
sudo htpasswd -c /etc/nginx/dsh.htpasswd you
sudo nginx -t && sudo systemctl reload nginx

nginx -t को syntax is ok और उसके बाद test is successful प्रिंट करना चाहिए। एक खराब फ़ाइल के साथ reload विफल हो जाता है और चल रहे configuration को वैसा ही छोड़ देता है, इसलिए आँख बंद करके restart करने के बजाय error को पढ़ें।

उनमें से तीन proxy लाइनें सजावट के लिए नहीं हैं। Upgrade और Connection headers WebSocket handshake को अनुमति देते हैं, और उनके बिना पेज लोड तो होता है लेकिन कभी अपडेट नहीं होता। proxy_read_timeout 3600s 60 सेकंड के डिफ़ॉल्ट को बदल देता है, जो अन्यथा एक लंबे agent run को रिस्पॉन्स के बीच में ही काट देता है और UI को फ्रीज दिखाता है। proxy_buffering off मॉडल आउटपुट को ब्राउज़र में आते ही भेज देता है, बजाय इसके कि रिस्पॉन्स पूरा होने तक उसे रोक कर रखे। एक nginx reverse proxy config, पंक्ति दर पंक्ति बाकी चीजों की व्याख्या करता है, और nginx, Caddy और Traefik के बीच चयन स्वचालित certificates के साथ यही काम करने के बारे में बताता है।

चाहे आप कोई भी proxy चुनें, firewall पर 3080 को बंद रखें, ताकि अंदर आने का एकमात्र रास्ता authenticated proxy ही हो। ufw firewall की बुनियादी बातें नियमों को कवर करती हैं। TLS पर basic authentication एक न्यूनतम सुरक्षा है, न कि पूर्ण सुरक्षा मॉडल: जिसके पास वह पासवर्ड है, उसके पास आपके सर्वर पर shell का एक्सेस है। जब संभव हो, tunnel को प्राथमिकता दें।

dsh web जिस पोर्ट पर listen करता है, उसे कैसे बदलें?

--port वेब एप्लिकेशन का हिस्सा है, न कि लॉन्चर का। CLI डॉक्यूमेंटेशन में इसका उदाहरण सीधे दिया गया है:

dsh --profile web --port 8080

dsh web, --profile web का ही एक alias है, इसलिए dsh web --port 8080 एक ही कमांड है। लॉन्चर केवल अपने स्वयं के flags को पार्स करता है और उनके बाद आने वाली हर चीज़ को बूट किए गए प्रोफाइल को सौंप देता है। इसलिए लॉन्चर के flags पहले आते हैं, और लॉन्चर द्वारा न पहचाना गया पहला टोकन एप्लिकेशन के arguments की शुरुआत करता है। --port को हमेशा प्रोफाइल के बाद रखें, पहले कभी नहीं।

कमांड द्वारा प्रिंट किए गए URL को पढ़ें, न कि यह मान लें कि वह क्या है, क्योंकि वह लाइन उस पते को दर्शाती है जिस पर सर्वर वास्तव में bind हुआ है। फिर अपने टनल के अंतिम फील्ड को उसके अनुसार अपडेट करें:

ssh -N -L 3080:127.0.0.1:8080 you@your-vps

स्थायी बदलाव के लिए, पोर्ट कमांड लाइन के बजाय प्रोफाइल कॉन्फ़िगरेशन में रहता है। web और headless प्रोफाइल पहली बार उपयोग किए जाने पर ~/.dsh के अंतर्गत दिए गए टेम्प्लेट से स्वतः इनिशियलाइज़ (auto-initialise) हो जाते हैं। वही डायरेक्टरी वह स्थान है जहाँ आपकी API key और model endpoint सेटिंग्स रहती हैं, इसलिए dsh keys, models और endpoints को कॉन्फ़िगर करना उन फाइलों को एडिट करते समय पढ़ने के लिए एक उपयोगी गाइड है। यह देखने के लिए कि सभी लेयर्स के जुड़ने के बाद वास्तव में क्या प्रभावी है:

dsh --dump-config

वेबसर्वर प्लगइन में केवल दो keys होती हैं, host और port। port को 0 पर सेट करने से ऑपरेटिंग सिस्टम से एक खाली पोर्ट मांगा जाता है, जिसे "शून्य का अर्थ OS द्वारा असाइन किया गया पोर्ट है" के रूप में डॉक्यूमेंट किया गया है। यह सुनिश्चित करता है कि आप कभी भी पोर्ट कॉन्फ्लिक्ट का सामना न करें, लेकिन यह टनल के लिए एक खराब विकल्प है, क्योंकि हर रीस्टार्ट पर यह नंबर बदल जाता है।

dsh 'address already in use' के साथ विफल क्यों होता है?

इसका कारण यह है कि कोई अन्य process पहले से ही उस address और port का उपयोग कर रही है, इसलिए kernel दूसरे bind अनुरोध को अस्वीकार कर देता है। Node इसे इस प्रकार रिपोर्ट करता है:

Error: listen EADDRINUSE: address already in use 127.0.0.1:3080

किसी भी बदलाव को करने से पहले यह पता लगाएँ कि उस port का उपयोग कौन कर रहा है:

sudo ss -ltnp | grep 3080

users:(("node",pid=1042,fd=21)) field उस process और उसके PID का नाम बताती है। इसका सामान्य उत्तर एक पिछला dsh होता है जिसके बारे में आपको लगा था कि वह बंद हो चुका है, लेकिन वह अक्सर किसी detached tmux window में चल रहा होता है। उसे kill 1042 के साथ बंद करें, या नए instance को किसी अलग port पर शुरू करें। ध्यान दें कि 127.0.0.1:3080 और 0.0.0.0:3080 भी आपस में टकराते हैं, क्योंकि सभी interfaces को bind करने का अर्थ loopback को भी कवर करना होता है।

वर्जन को पिन करें, क्योंकि यह एक डेवलपर प्रीव्यू है

README इस बारे में स्पष्ट है: DeepSeek Harness अभी डेवलपर प्रीव्यू में है और इसमें तेजी से बदलाव हो रहे हैं, जिसके कारण compatibility-breaking बदलाव हो सकते हैं। यदि यही गति आपकी हिचकिचाहट का कारण है, तो dsh की Claude Code और Omnigent से तुलना इसे एक ही कर्व पर अलग-अलग चरणों में मौजूद दो अन्य हार्नेस के साथ तौलती है।

npx @deepseek-ai/dsh web हर बार रन करने पर सबसे नए पब्लिश किए गए वर्जन को रिज़ॉल्व करता है। एक सर्वर जिसे आपने एक हफ्ते से नहीं छुआ है, वह अपने अगले लॉन्च पर एक अलग CLI शुरू कर सकता है, जिसमें अलग flags हो सकते हैं। वर्जन को पिन करें ताकि रीस्टार्ट का मतलब अपग्रेड न हो:

npx @deepseek-ai/dsh@0.1.0-rc.7 web

अगस्त 2026 तक पब्लिश किया गया पैकेज वर्जन 0.1.0-rc.7 है। यह जांचें कि एक साधारण npx स्वीकार करने से पहले वह क्या पुल करेगा:

npm view @deepseek-ai/dsh version

यदि पिन इंस्टॉल होने से मना कर दे, या नया वर्जन पिन करने के बाद भी npx पुराना बिल्ड ही शुरू करता रहे, तो इंस्टॉल और वर्जन संबंधी त्रुटियां में npx कैश को क्लियर करने और यह जांचने का तरीका बताया गया है कि आपका Node कौन सा npm बंडल इस्तेमाल कर रहा है।

प्रीव्यू रिलीज़ के दौरान flags लॉन्चर और वेब एप्लिकेशन के बीच बदलते रहते हैं। यदि --port उस तरह व्यवहार करना बंद कर दे जैसा इस गाइड में बताया गया है, तो अनुमान लगाने के बजाय एप्लिकेशन से ही उसकी फ्लैग लिस्ट मांगें:

dsh --profile web --help

इंस्टॉल, वर्कस्पेस सेटअप और मॉडल की (model key) के लिए, VPS पर DeepSeek Harness इंस्टॉल करना देखें। केवल एक्सेस स्टेप के संक्षिप्त विवरण के लिए, VPS पर dsh Web UI तक पहुंचना टनल के बारे में जानकारी देता है।

FAQ

मैं अपने लैपटॉप ब्राउज़र में http://127.0.0.1:3080 क्यों नहीं खोल पा रहा हूँ?

क्योंकि 127.0.0.1 का अर्थ वह मशीन है जिस पर आप टाइप कर रहे हैं। DeepSeek Harness Web UI, VPS के loopback address से बंधा (bound) है, इसलिए केवल VPS पर चल रही प्रक्रियाएँ ही इससे जुड़ सकती हैं। आपके लैपटॉप का अपना अलग loopback है, और वहाँ port 3080 पर कोई भी service listening नहीं है। SSH के माध्यम से ssh -N -L 3080:127.0.0.1:3080 you@your-vps का उपयोग करके port forward करें, और फिर स्थानीय रूप से http://127.0.0.1:3080 लोड करें। -L तर्क (argument) का मध्य क्षेत्र सर्वर साइड पर resolve होता है, जो इसे harness की ओर इंगित करता है।

क्या सार्वजनिक VPS पर dsh Web UI को 0.0.0.0 पर bind करना सुरक्षित है?

नहीं। Web UI उस agent के लिए control surface है जो dsh चलाने वाले उपयोगकर्ता के रूप में shell commands चलाता है और फ़ाइलें संपादित करता है, और developer preview में कोई login screen नहीं है। सार्वजनिक IP पर सभी interfaces को bind करने का अर्थ है कि port 3080 तक पहुँचने वाला कोई भी व्यक्ति आपके सर्वर पर command निष्पादित कर सकता है। bind को 127.0.0.1 पर रखें, firewall पर 3080 को बंद रखें, और SSH tunnel, private overlay network, या password की आवश्यकता वाले reverse proxy का उपयोग करें।

SSH session बंद करने के बाद मैं dsh Web UI को कैसे चालू रखूँ?

एक foreground npx @deepseek-ai/dsh web आपके login shell का child होता है, इसलिए shell बंद होने पर वह भी समाप्त हो जाता है। इसे tmux session के अंदर शुरू करें और Ctrl-b d के साथ detach करें, या lingering सक्षम करके इसे systemd user service के रूप में चलाएँ। tunnel और harness स्वतंत्र हैं: आप जब तक चाहें SSH tunnel को हटा और फिर से बना सकते हैं, बिना चलते हुए harness को प्रभावित किए, बशर्ते harness का parent आपके login से अधिक समय तक जीवित रहे।

nginx के पीछे लंबे agent run के दौरान dsh Web UI बीच में ही क्यों रुक जाता है?

क्योंकि nginx का डिफ़ॉल्ट proxy_read_timeout 60 सेकंड है, इसलिए यह उस connection को बंद कर देता है जो एक मिनट तक कोई डेटा नहीं भेजता, जो कि एक लंबे agent step में आसानी से हो सकता है। location ब्लॉक में proxy_read_timeout 3600s; सेट करें। proxy_buffering off; जोड़ें ताकि output ब्राउज़र में आते ही stream हो जाए, और WebSocket handshake सफल होने के लिए proxy_http_version 1.1; के साथ Upgrade और Connection headers पास करें। इन headers के बिना पेज लोड तो होता है लेकिन कभी कोई अपडेट प्राप्त नहीं होता।