इमेज दूसरी साइट पर ब्रोकन? 403 और हॉटलिंक प्रोटेक्शन ट्रबलशूटिंग (2026)
आपने एक इमेज का लिंक ब्लॉग में लगाया, लोकल प्रीव्यू में सब बढ़िया। पब्लिश किया, और दूसरों को दिखता है एक टूटा हुआ आइकन फ़्रेम। या उससे भी बुरा — पूरी इमेज की जगह एक सफ़ेद खाली पैच, कुछ नहीं।
यह गड्ढा मैं एक बार से ज़्यादा खोद चुका हूँ। लाइव पर एक बार फटा था जब दोस्त के फ़ोरम की इमेज माइग्रेट कर रहा था — लोकल पर सब हरा, लाइव होते ही होमपेज के एक तिहाई थंबनेल ब्रोकन, और मुझे लगा कैश साफ़ नहीं हुआ। तीन दिन debug के बाद पता चला, समस्या मेरी थी ही नहीं — इमेज सोर्स साइट ने हॉटलिंक प्रोटेक्शन चालू कर रखी थी, अपने डोमेन के अलावा किसी और से आई रिक्वेस्ट को सीधे रोक देती थी।
वास्तुकला के नज़रिए से देखें तो "इमेज दूसरी साइट पर नहीं दिखती" असल में तीन बिल्कुल अलग फ़ेलियर एक साथ मिलाकर बोले जाते हैं। सही फ़िक्स के लिए पहला कदम है पहचानना कि आपके साथ कौन-सा हुआ है।
पहले फ़र्क़ करो: 403, ब्रोकन इमेज, और 200 खाली — तीन अलग चीज़ें
बहुत लोग इमेज ग़ायब देखते ही सबको "ब्रोकन इमेज" कह देते हैं और अंधाधुंध कोशिश शुरू। सच यह है कि इन तीनों लक्षणों की जड़ बहुत अलग है, और ट्रबलशूटिंग का रास्ता भी।
| लक्षण | HTTP स्टेटस | सबसे संभावित जड़ | ट्रबलशूट दिशा |
|---|---|---|---|
| टूटा आइकन फ़्रेम | 403 / 404 | हॉटलिंक ब्लॉक, या लिंक ख़ुद ग़लत | Referer और url सही जाँचो |
| टूटा आइकन फ़्रेम | 200 पर इमेज नहीं | मिला HTML एरर पेज, इमेज फ़ाइल नहीं | Content-Type जाँचो |
| सफ़ेद खाली (बिना टूटे आइकन) | 200 | CSS ढक रहा, या CSP लोड रोक रहा | DevTools Console और CSP जाँचो |
| आइकन घूमकर ग़ायब | टाइमआउट / CORS | क्रॉस-डोमेन पॉलिसी या सर्वर टाइमआउट | Network की request डिटेल जाँचो |
पहले स्टेटस कोड, फिर Content-Type, आख़िर में स्क्रीन। यह क्रम उल्टा किया तो सिर पटकते रहोगे।
अंदरूनी सिद्धांत: Referer और हॉटलिंक प्रोटेक्शन कैसे काम करते हैं
दूसरी साइट की इमेज क्यों रुकती है, यह समझने के लिए पहले जानना होगा कि ब्राउज़र इमेज लोड करते वक़्त चुपके से क्या करता है।
जब पेज A <img src="https://B.com/photo.jpg"> से B साइट की इमेज लोड करता है, तो ब्राउज़र की रिक्वेस्ट में एक Referer हेडर जुड़ता है (हाँ, यह शब्द इतिहास में ग़लत स्पेल हुआ, एक r कम, और वही ग़लती आज तक चल रही है)। यह हेडर B साइट को बताता है: "यह इमेज A साइट के पेज से माँगी गई है।"
अंदरूनी लॉजिक ऐसी है: B साइट का सर्वर या CDN रिक्वेस्ट मिलते ही Referer के डोमेन को एक व्हाइटलिस्ट से मिलाता है। मिलान लगभग ऐसे —
1. Referer खाली है (सीधे इमेज खोली, बुकमार्क) → सेटिंग तय करेगी पास या ब्लॉक
2. Referer का डोमेन व्हाइटलिस्ट में → पास
3. Referer का डोमेन व्हाइटलिस्ट में नहीं → 403 Forbidden
यही हॉटलिंक प्रोटेक्शन है। इसका मक़सद सीधा है: कोई और आपका बैंडविड्थ मुफ़्त में न खाए। आपने अपनी साइट पर B की इमेज एम्बेड की, हर बार कोई आपका पेज देखे तो ट्रैफ़िक का बिल B के सिर, B को नागवार लगेगा ही।
एक बारीकी जो बहुत लोग नहीं जानते: आधुनिक ब्राउज़र का डिफ़ॉल्ट Referrer-Policy है strict-origin-when-cross-origin। क्रॉस-डोमेन रिक्वेस्ट पर वो सिर्फ़ "सोर्स डोमेन" (जैसे https://a.com/) भेजता है, पूरा path नहीं। तो हॉटलिंक प्रोटेक्शन को आपका डोमेन नाम मिल जाता है, व्हाइटलिस्ट मिलाने और आपको रोकने के लिए काफ़ी। इसीलिए हॉटलिंक प्रोटेक्शन hotlink को रोक पाती है।
आपकी इमेज दूसरी साइट पर क्यों टूटती है: एक ट्रबलशूटिंग ट्री
ऊपर के सिद्धांत को खोलें तो ब्रोकन इमेज की जड़ एक ट्री में सिमट जाती है। बस नीचे-नीचे चलते जाओ।
शाखा 1: क्या स्टेटस कोड 403 है?
हाँ तो 90% हॉटलिंक प्रोटेक्शन। B साइट ने देखा आपका Referer उसकी व्हाइटलिस्ट में नहीं, सीधे मना। यहाँ आप B की सेटिंग नहीं बदल सकते, इकलौता हल — उसकी इमेज hotlink करना बंद करो (सही तरीक़ा आगे)।
शाखा 2: स्टेटस 200 है, पर स्क्रीन ब्रोकन?
इस "इमेज" का रॉ कंटेंट देखो। बहुत मुमकिन है आपको एक HTML पेज मिला — कुछ साइट 403 नहीं देतीं, बल्कि "hotlink मत करो" वाला एक पेज देती हैं, स्टेटस फिर भी 200। ब्राउज़र HTML को इमेज समझकर पार्स करता है, तो टूट जाता है। Content-Type देखो, राज़ खुल जाएगा: सामान्य इमेज image/jpeg, image/png, एरर पेज text/html।
शाखा 3: आपने "पेज लिंक" लगाया, "इमेज डायरेक्ट लिंक" नहीं?
नए लोगों का सबसे आम जाल। https://imgur.com/aBcDeFg एक पेज है, https://i.imgur.com/aBcDeFg.jpg ही असली इमेज फ़ाइल है। पहले वाले को <img src> से लोड करो तो पूरा HTML पेज मिलता है, इमेज नहीं। बस एक i. और एक्सटेंशन का फ़र्क़, नतीजा ज़मीन-आसमान।
शाखा 4: क्या Referrer-Policy ने आपको ख़ुद फँसाया?
ज़्यादा छिपा हुआ मामला। अगर आपके पेज पर Referrer-Policy: no-referrer सेट है, तो ब्राउज़र इमेज लोड करते वक़्त Referer भेजता ही नहीं। कुछ हॉटलिंक सेटिंग "खाली Referer एकदम ब्लॉक" वाली होती हैं, और आप अपनी ही प्राइवेसी सेटिंग से बाहर बंद हो जाते हो। टेस्ट में यह केस अक्सर उन साइटों पर मिलता है जो प्राइवेसी को लेकर बहुत सख़्त हैं और meta referrer एकदम बंद कर देती हैं।
हाथ से डायग्नोसिस: DevTools और curl दो तरीक़े
सिद्धांत हो गया, अब असल में जाँचें कैसे? मैं दो टूल पक्के इस्तेमाल करता हूँ, पाँच मिनट में 90% ब्रोकन इमेज पकड़ लेते हैं।
तरीक़ा 1: DevTools Network पैनल
ब्राउज़र डेवलपर टूल खोलो (F12), Network टैब पर जाओ, पेज रिफ़्रेश करो, फ़िल्टर में इमेज फ़ाइल का नाम डालो। उस रिक्वेस्ट पर क्लिक करके तीन चीज़ें देखो:
- Status: 403, 404 या 200?
- Response Headers का
Content-Type:image/*याtext/html? - Request Headers का
Referer: असल में क्या भेजा गया? खाली या आपका डोमेन?
तीनों देखकर जड़ लगभग सामने आ जाती है।
तरीक़ा 2: curl से मैनुअल Referer कंट्रोल
DevTools लक्षण दिखाता है, पर "यह सच में हॉटलिंक है या नहीं" वेरिफ़ाई करने में curl सबसे सीधा। आप मैनुअली कोई भी Referer भर सकते हो और देख सकते हो सर्वर का जवाब कैसे बदलता है:
# बिल्कुल बिना Referer (सीधे इमेज खोलने जैसा)
curl -I "https://example.com/photo.jpg"
# "सोर्स साइट का अपना" होने का नाटक करता Referer
curl -I -H "Referer: https://example.com/" "https://example.com/photo.jpg"
# "आपकी बाहरी साइट से" वाला Referer
curl -I -H "Referer: https://your-blog.com/" "https://example.com/photo.jpg"
पढ़ना सीधा है। अगर पहला और तीसरा 403 दें, पर दूसरा 200 — बधाई, हॉटलिंक प्रोटेक्शन पक्की। सर्वर सिर्फ़ सोर्स साइट का अपना Referer पहचानता है, बाक़ी सब ब्लॉक। तीनों 200 दें, तो ब्रोकन इमेज का हॉटलिंक से कोई लेना-देना नहीं, वापस अपना url या CSP जाँचो।
मेरी आदत तीनों साथ चलाने की है, नतीजों की तुलना एक-एक से कहीं साफ़ है। इसीलिए curl ब्राउज़र में अंधा क्लिक करने से ज़्यादा असरदार।
आम इमेज होस्टिंग / CDN का हॉटलिंक बर्ताव
अलग सर्विस का डिफ़ॉल्ट मिज़ाज बहुत अलग होता है। नीचे मेरे इन सालों के इमेज माइग्रेशन के अनुभव हैं, असली सेटिंग हर सर्विस कभी भी बदल सकती है, पर बड़ी दिशा यही है।
| सर्विस टाइप | डिफ़ॉल्ट हॉटलिंक ब्लॉक? | खाली Referer बर्ताव | बाहरी साइट डायरेक्ट लिंक ठीक? |
|---|---|---|---|
| सेल्फ़-होस्टेड Nginx / Apache | आप जैसे सेट करो | आमतौर पर पास | सेटिंग पर निर्भर |
| एंटरप्राइज़ CDN (व्हाइटलिस्ट) | खोल-बंद कर सकते | पास या ब्लॉक सेट कर सकते | सही सेट तो हाँ |
| कुछ फ्री होस्टिंग | अक्सर चालू | अक्सर ब्लॉक | अक्सर ब्लॉक |
| सोशल प्लैटफ़ॉर्म का इमेज डोमेन | लगभग सब चालू | लगभग सब ब्लॉक | नहीं, भूल जाओ |
| शेयरिंग-फ़ोकस्ड होस्टिंग | आमतौर पर बंद | पास | हाँ, यही तो इसका मक़सद है |
अहम बात आख़िरी लाइन। सोशल प्लैटफ़ॉर्म (उन सोशल साइटों के CDN डोमेन) की इमेज का url कॉपी करके बाहर लगभग सौ फ़ीसदी हॉटलिंक नहीं होगा, क्योंकि उनका बिज़नेस मॉडल आपको साइट के अंदर बाँधे रखना है। उन इमेज को कहीं और लगाने की सोचो — बंद रास्ता।
और "शेयरिंग"-फ़ोकस्ड होस्टिंग में हॉटलिंक डिफ़ॉल्ट बंद होता है — उसके होने का मक़सद ही है कि आपकी इमेज बाहरी साइट पर टिकाऊ लोड हो। इन दो टाइप को कभी मत मिलाओ।
Referrer-Policy का जाल: ब्राउज़र भी आपको उल्टा फँसा सकता है
पहले एक छिपे केस का ज़िक्र किया, यहाँ खोलकर बताता हूँ, क्योंकि यह debug करते-करते ज़िंदगी पर शक करा देता है।
Referrer-Policy वो हेडर है जिसे पेज (रिक्वेस्ट भेजने वाला) सेट करता है। यह तय करता है ब्राउज़र कितनी Referer जानकारी भेजे। कई वैल्यू हैं:
no-referrer: बिल्कुल नहीं भेजता।origin: सिर्फ़ सोर्स डोमेन।strict-origin-when-cross-origin: क्रॉस-डोमेन पर सिर्फ़ डोमेन, HTTP पर गिरे तो कुछ नहीं (आधुनिक डिफ़ॉल्ट)।unsafe-url: पूरा path भी (सुझाया नहीं, प्राइवेसी लीक)।
विरोधाभास यहाँ है। हॉटलिंक प्रोटेक्शन को सोर्स पहचानने के लिए Referer चाहिए, पर प्राइवेसी पॉलिसी कम या बिल्कुल न भेजने को उकसाती है। जब कोई साइट प्राइवेसी के लिए no-referrer सेट करती है और किसी हॉटलिंक-प्रोटेक्टेड, "खाली Referer एकदम ब्लॉक" वाली इमेज को लोड करती है, तो सब टूट जाती हैं।
मैं लाइव पर एक बार ऐसे ही फटा — एक बहुत प्राइवेसी-सजग साइट, पूरी साइट पर no-referrer, नतीजा सारी बाहरी इमेज ब्रोकन। तब मुझे लगा होस्टिंग डाउन है, आधे दिन जाँचने के बाद पता चला मेरी ही meta सेटिंग ने Referer का गला घोंट दिया। यह जाल आसानी से दिमाग़ में नहीं आता, क्योंकि "प्राइवेसी बढ़ाना" ख़ुद को कैसे नुक़सान करेगा?
सही तरीक़ा: दूसरों की इमेज hotlink मत करो
ट्रबलशूट के आख़िर में एक कड़वा सच सामने आता है: जब तक इमेज आपकी अपनी होस्ट की नहीं है, कोई भी "दूसरी साइट की इमेज" किसी भी वक़्त बिना बताए ग़ायब हो सकती है। सामने वाला हॉटलिंक बदले, url बदले, फ़ाइल हटाए, या पूरी साइट बंद करे — आपका पेज साथ टूटता है।
सच में टिकाऊ तरीक़े सिर्फ़ दो।
पहला, इमेज को अपने कंट्रोल वाली जगह पर दोबारा होस्ट करो। दूसरों का url सीधे एम्बेड मत करो। इमेज डाउनलोड करो, अपनी जगह या बाहरी लिंक-अनुमति वाली होस्टिंग पर अपलोड करो, उस स्थिर url का इस्तेमाल करो। वास्तुकला के नज़रिए से इस कदम का मतलब है अपने पेज की उपलब्धता दूसरों के सर्वर के हाथ से वापस अपने हाथ में लाना — सोर्स आपके क़ाबू में न हो, तो उसका कोई भी हॉटलिंक बदलाव, url रीस्ट्रक्चर, या पूरी साइट डाउन होना सीधे आपके पेज पर ब्रोकन इमेज बनकर उतरेगा, और आपको चेतावनी तक नहीं मिलेगी, अक्सर पाठक ही बताते हैं कि फट गया। अगर आपके पास दूसरों के डोमेन पर बिखरे पुराने लिंक का एक पूरा बैच एक बार में साफ़ करना है, तो मैंने एक अलग इमेज लिंक बैच रिप्लेस का पूरा SOP लिखा है, स्क्रिप्ट से पूरी साइट के पुराने url स्कैन करके एक बार बदलना, हाथ से एक-एक बदलने से कहीं आसान।
दूसरा, ऐसी होस्टिंग चुनो जिसमें हॉटलिंक डिफ़ॉल्ट बंद हो। बहुत फ्री होस्टिंग बैंडविड्थ बचाने को बाहरी लिंक रोकती हैं, फ़ोरम या ब्लॉग पर लगाओ तो ब्रोकन दिखाती हैं। बाहरी लिंक चाहिए तो साफ़ तौर पर डायरेक्ट लिंक अनुमति देने वाली सर्विस चुनो।
यह lpic.cc बनाते वक़्त हमारा एक सिद्धांत भी था: अपलोड के बाद आपको एक स्थिर इमेज डायरेक्ट लिंक मिलता है, बाहरी साइट डिफ़ॉल्ट रूप से नहीं रुकती, ताकि फ़ोरम, ब्लॉग, Discord कहीं भी सही दिखे, बेवजह 403 न बने। निजी इमेज के लिए पासवर्ड प्रोटेक्शन से कंट्रोल कर सकते हो कौन देखे। आज़माना हो तो एक इमेज फ्री अपलोड करके लिंक किसी और पेज पर लगाकर देख लो टिकता है या नहीं।
सच कहूँ तो लिमिट भी ईमानदारी से बता दूँ: अभी फ्री प्लान में इमेज 30 दिन स्टोरेज, स्थायी आर्काइव नहीं, और सर्विस विज्ञापन-समर्थित है। लंबे आर्काइव या कमर्शियल बड़े इमेज लाइब्रेरी के लिए किसी पेड प्रोफ़ेशनल प्लान या बैकअप वाली अपनी स्टोरेज पर विचार करो। टूल सही जगह चुनने पर ही काम का है — यह मैंने गड्ढे में गिरकर सीखा।
अक्सर पूछे जाने वाले सवाल (FAQ)
Q: एक ही इमेज लिंक मुझे खुलता है, दूसरी साइट पर लगाते ही क्यों टूटता है?
क्योंकि "सीधे इमेज खोलते" वक़्त Referer खाली या अनुमति वाले सोर्स से होता है, हॉटलिंक पास कर देती है। दूसरी साइट पर लगाने पर Referer वो बाहरी डोमेन बन जाता है, व्हाइटलिस्ट में नहीं, तो 403। एक ही url, अलग Referer, नतीजा बिल्कुल अलग।
Q: क्या 403 और ब्रोकन इमेज एक ही चीज़ हैं?
नहीं। 403 सर्वर का साफ़ इनकार है (स्टेटस 403), ब्रोकन इमेज सिर्फ़ ब्राउज़र का "इमेज न बना पाना" वाला दृश्य है। 403 ब्रोकन इमेज बनाता है, पर ब्रोकन इमेज url ग़लती, Content-Type ग़लती, CSP ब्लॉक जैसी दूसरी वजहों से भी हो सकती है। पहले स्टेटस देखो तभी पता चलेगा कौन-सी है।
Q: पेज को Referrer-Policy: no-referrer सेट करने से हॉटलिंक बायपास होगी?
कभी हाँ, कभी उल्टा और बुरा। अगर सामने वाले की हॉटलिंक "खाली Referer पास" वाली है, तो Referer न भेजना काम कर जाएगा। पर अगर "खाली Referer एकदम ब्लॉक" वाली है, तो सब टूटेंगी। यह तरक़ीब भरोसेमंद नहीं, इसे सही हल मत मानो।
Q: मैं प्रोग्राम (Python / Node) से इमेज खींचूँ तब भी 403, क्या करूँ?
ब्राउज़र जैसा ही — आपके प्रोग्राम ने सही Referer नहीं भेजा। पहले curl से टेस्ट करो सामने वाला कौन-सा Referer पहचानता है, फिर अपनी HTTP रिक्वेस्ट में वही हेडर जोड़ो। पर ध्यान: दूसरों की हॉटलिंक बायपास करके इमेज खींचना उनकी सर्विस शर्तों का उल्लंघन हो सकता है, ख़ुद तौलो।
Q: तेज़ी से कैसे जानूँ कि कोई होस्टिंग बाहरी लिंक होने देती है?
एक टेस्ट इमेज अपलोड करो, उसका डायरेक्ट लिंक लो, curl -I -H "Referer: https://google.com/" चलाओ। 200 आए तो बाहरी लिंक अनुमति; 403 आए तो हॉटलिंक प्रोटेक्शन है, बाहर मत लगाओ। तीस सेकंड में जाँच।
संदर्भ (References)
- MDN Web Docs — Referrer-Policy header (एक्सेस: 2026-06-26)
- AWS Security Blog — How to prevent hotlinking using referer checking, AWS WAF, and CloudFront (एक्सेस: 2026-06-26)
- Alibaba Cloud CDN — Configure a Referer whitelist or blacklist for hotlink protection (एक्सेस: 2026-06-26)
- KeyCDN Support — Create a Zone Referrer (Hotlink Protection) (एक्सेस: 2026-06-26)
- ProxiesAPI — Fixing 403 Forbidden Errors for Image Requests in Code (एक्सेस: 2026-06-26)
- Patchstack — How To Prevent Image Hotlinking in WordPress (एक्सेस: 2026-06-26)