There's the new image hosting system and Super User (my main "playground") is trialling it.

My problem is I cannot see images hosted on i.sstatic.net. This is how it looks like:

placeholder instead of an image

This particular screenshot is from the following question: USB-C Splitter for external SSD enclosure. The link to the image is https://i.sstatic.net/KnVuyq7G.jpg and when I click it I see:

oh no, that request didn't look right RayID: 872140670bf8772e

wget 'https://i.sstatic.net/KnVuyq7G.jpg' gives me:

--2024-04-10 10:12:58--  https://i.sstatic.net/KnVuyq7G.jpg
Resolving i.sstatic.net (i.sstatic.net)...,
Connecting to i.sstatic.net (i.sstatic.net)||:443... connected.
HTTP request sent, awaiting response... 400 Bad Request
2024-04-10 10:12:59 ERROR 400: Bad Request.

curl -o result 'https://i.sstatic.net/KnVuyq7G.jpg' gives me the following content in the result file:

<!DOCTYPE html> <html> <head> <link rel='stylesheet' href='https://fonts.googleapis.com/css?family=Arimo'> <style> body { font-family: 'Arimo', sans-serif; text-align: center; font-size: .9em; background-color: white; color: gray } .container { display: flex; flex-direction: column; align-items: center; justify-content: center; height: 100vh; } img { max-width: 100%; height: auto; } </style> 
</head> <body> <div class='container'> <img src='https://i.sstatic.net/wiC8UD6Y.png'> <p>oh no, that request didn't look right<br>RayID: 872149dd09dabfc6</br></p> </div> </body> </html>

The above describes how the situation looks at my home, let's call it Location A. I have SSH access to a remote computer, Location B (details below). There I can also do wget 'https://i.sstatic.net/KnVuyq7G.jpg' and the result is:

Downloading 'https://i.sstatic.net/KnVuyq7G.jpg'
Connecting to
Writing to 'KnVuyq7G.jpg'
KnVuyq7G.jpg         100% |*******************************|   202k  0:00:00 ETA
Download completed (207108 bytes)

Then file KnVuyq7G.jpg reports:

KnVuyq7G.jpg: JPEG image data, JFIF standard 1.01, aspect ratio, density 1x1, segment length 16, baseline, precision 8, 1200x1600, components 3

so from B the link works fine.

Now the crazy part: once the link is accessed from B, it starts working when accessed from A! Now I can refresh the linked question in my browser and the image is there. I can wget on A, there is no longer 400 Bad Request; and I can curl on A, there is no longer oh no, that request didn't look right. Each method shows or downloads the proper .jpg file.

So the action on B fixed the problem with this particular image on A. This makes me believe the problem is not on my computer(s) in the Location A. I suspect there is something wrong with the content delivery network or so.

Can you fix this globally, so I can simply (without tricks) see images posted on Stack Exchange? Or is the problem nevertheless on my side? Or the ISP's? I'm posting few RayIDs down below, hopefully they will help.

I'm also curious about the mechanism that allows actions of B affect abilities of A to access resources. If it's really a problem with the content delivery network and some developer briefly explains what happened then this will be a nice bonus.


  • Location A is not a single computer. I have tested from few computers. Location A consists of:

    • my home with

      • a home router with Debian 12 implementing NAT
      • a laptop with Kubuntu 23.10 with Vivaldi browser behind the NAT
    • my workplace where I also tested on

      • a virtual machine with Debian 12 behind (another) NAT

    My home and my workplace share an ISP. Each uses a separate IPv4 address in the range. The addresses are globally routable.

  • Location B is a home router I can access via SSH, it runs some version of OpenWRT. It's in a different town than A, it uses a different ISP than A. It's behind CGNAT and the public IP address is 185.138.239.xxx.

  • Location A and Location B are in Poland.

  • To be clear: fixing links for A involves no tunneling nor proxying via B. The sole act of accessing a link from B magically fixes it for A.

  • There is virtually no delay: a link does not work on A, I run wget on B, in few seconds I refresh it on A and it suddenly works.

  • I have fixed several links this way. The method worked each time exactly as stated. For now it's my only firm way to deal with the problem.

  • I have observed few images that started showing on A "by themselves". I suspect in this case some random user(s) of the Internet had done the job of B for me.

  • The example link was posted on Super User, but I have also observed the problem on Ask Ubuntu (e.g. here).

  • I'm using my laptop in the Location A to ask this very question. I was afraid I wouldn't be able to add images, but the site still uses Imgur and there was no problem. As a test I started writing a question on Super User, uploaded an image and encountered oh no, that request didn't look right from i.sstatic.net. In other words I couldn't see the file I have uploaded… until I accessed it from B which again fixed it for A. This means the act of uploading from A went well.

  • In my tests i.sstatic.net resolved either to or to It seems it doesn't matter which IP address is used at which stage, the problem and my method of dealing with it behave consistently.

  • RayIDs of my unsuccessful tries to access https://i.sstatic.net/KnVuyq7G.jpg from A: 872140670bf8772e, 872149dd09dabfc6. This is one of the images I have already fixed by accessing from B.

  • RayIDs of my unsuccessful tries to access another image uploaded by me: 8721e856df81353a, 8721e999fe58353a. I have not fixed this image by accessing its link from B; I'm not going to. I deliberately do not post the link, so hopefully nobody inadvertently fixes it before the right person or team starts investigating.


One scenario that (I think) makes sense is:

  1. Initial requests from A do not find the resource (image) on CDN nodes in geographical proximity. The requests ultimately go to a distant server that refuses serving to the IP addresses of A for some reason.

  2. A request from B ultimately goes to the same or to another server that serves the resource to the IP address of B successfully.

  3. The resource gets copied to a node (or cache) closer to B automatically.

  4. It so happens this node (or cache) is the best choice when A requests the resource again.

  5. It so happens this node (or cache) has no problem with serving to the IP addresses of A.

With this hypothesis the "crazy part" is no longer that crazy.


As a workaround I have set up a SOCKS proxy in B and I use it from A only to access i.sstatic.net. The actual setup is more convoluted, it involves VPN and SSH connections I had been using even before the problem started.

Still I'm hoping for a fix that will make the things just work. The question stands.


I've been asked to post more recent RayIDs, here they are (from 2024-05-02, around 19:30 UTC):

  • 87da5fd72dbd357e, 87da606e9963357e.

    The resource is https://i.sstatic.net/KnVuyq7G.jpg , accessed from A. This is one of the images I had fixed by accessing from B, but I have just discovered it is unavailable to A again. So I have just fixed it again by accessing from B. Nothing has changed; accessing from B fixed it for A, but now I strongly suspect this is a temporary fix that needs to be renewed.

  • 87da6ced4f7d357e, 87da6e511844357e

    The resource is the already mentioned image uploaded by me, accessed from A; the one I was not going and I'm not going to fix by accessing from B.

To be clear: I have disabled my workaround (the SOCKS proxy) in order to obtain the above RayIDs.

  • 6
    Some kind of Cloudflare protection, they identify the IP as bad for some reason. Commented Apr 10 at 10:57
  • 2
    I think the problem is on your (or your ISP's) side--I have not noticed any issues with images on the new domain.
    – TylerH
    Commented Apr 10 at 15:31
  • 4
    I get this exact error on my work laptop while at the office, but when I work from home on the exact same computer, everything works. Just my network that changed.
    – pipe
    Commented Apr 12 at 6:47
  • 7
    I experience the same issue for all images on Stack Exchange sites. It's extremely inconvenient. Wonder if there are any solutions. Commented Apr 12 at 15:30
  • 2
    Please add the workaround as answer. Commented Apr 28 at 11:07
  • 5
    @ShadowWizardLoveZelda The main question is: "Can you fix this globally, so I can simply (without tricks) see images posted on Stack Exchange?" It is addressed to the powers/devs/etc. of Stack Exchange and/or Cloudflare (indirectly). My workaround is a trick in this context, it's totally not an answer. Commented Apr 28 at 14:05
  • 2
    @ShadowWizardLoveZelda Workarounds, if posted by the author, are better edited into the question rather than posted as answers. If found by others, then they're better as answers. Commented Apr 29 at 0:46
  • 1
    @Sonic I disagree, but that's not something I'll fight over. Commented Apr 29 at 8:28
  • 5
    Two questions. First, could I ask you to post a more recent Ray ID? Ideally from within the last day or so. Second, for folks who are saying they experience the same issue - do you mean that you're having trouble loading images on a certain network generally, or does it work the exact same way as OP describes, where loading the image via another IP then allows you to load the image on your network?
    – Slate StaffMod
    Commented May 2 at 19:13
  • 1
    @Slate RayIDs added. Revision 7. Commented May 2 at 19:36
  • 7
    @Kamil Thanks, I've passed it along for review.
    – Slate StaffMod
    Commented May 2 at 19:40
  • 1
    Exact same issue. Loading from another network(mobile phone) logged on as same user, fixes the issue on the device connected through another ISP. RayID: 88354dd0cb2abc16, RayID: 88354e7d6bfabc16, RayID: 88354f67c976bc16, RayID: 883550d47cf8bc16, RayID: 8835518638aabc16 Commented May 13 at 20:17
  • Same issue on my home network. Ray ID from today: 89308b4ba9cf2d62. Commented Jun 13 at 8:03
  • 3
    @Slate - Hi, We're continuing to get reports in comments here on the question & on the answer from Josh Zhang from other users who are getting (what appears to be) the same problem. Are those actually being passed to dev or investigated in any other way? There doesn't seem to be any response and I'm concerned the current "status-norepro" might mean they are being ignored. || This is what I was concerned might happen and it was why I asked how others should report this, but I didn't get a reply to that specific point :( Can you update, please? TY
    – SamGibson
    Commented Jun 13 at 8:15

2 Answers 2


I had this issue in the last 2 months and thought it was due to other reasons. Ubuntu 24.04 here and just signed up for a week on a free wiregaurd vpn server close to my location. Now whenever there is a need to see picture/s just activating the vpn will make them visible and even when you turn vpn off they re visible. There is really no need to have a vpn on this system except for displaying the images.

Update: I have signed up for another week on the same wiregaurd server and it works. No more updates until / if seeing pictures works without vpn.

  • 1
    You contradict yourself: on one hand "really no need to have a vpn on this system", but also "activating the vpn will make them visible". So VPN is essential. Commented Jul 8 at 6:50
  • 2
    Edited the answer.
    – amar
    Commented Jul 8 at 7:02

Thanks for all the detailed information, that helped us dig quite deep into the issues you're experiencing!

Unfortunately after looking at our front and back end logs, we believe this issue is only happening to you. Others on your ISP don't have any issues accessing images on i.sstatic.net. We checked the CDN server you're accessing the images from, our back end server, along with trying to reproduce your errors using proxies and other devices. Ultimately we were unable to reproduce the error you're getting with any of the combinations we tested.

  • 1
    Josh - Hi, You said to the OP that "we believe this issue is only happening to you". However please note that there were comments from (currently 2) other people saying they are affected with the same symptoms, pipe & Martynas Žiemys. I realise you didn't get the same detailed info from them (I don't think anyone asked them to provide it), but I'm concerned that a reply that this only affects the OP appears to have overlooked those comments. How do you want any other people who believe they are also affected, to report this? TY
    – SamGibson
    Commented May 3 at 19:48
  • 4
    What others have described in the comments have similar symptoms but are not the same issue. The others are more than likely Hotlink Protection. Thanks to the RayID that was provided, the errors from this report are http 400 which is unique to this user's attempts. What's unique about this situation is that loading the image in a different location makes the image visible from that point forth. Other's issues are certain networks will never be able to see the image due to various factors.
    – Josh Zhang StaffMod
    Commented May 3 at 19:56
  • 1
    @Josh How can you determine for certain "Others on your ISP, don't have any issues accessing images"? Do you have log of requests for images with ISP details? Commented May 3 at 20:36
  • 4
    We checked the subnets provided in the post and also corroborated with the provided RayID's. Using those, we know which ASN and Cloudflare datacenter the traffic is going through. We filtered all traffic from the ASN, and also the Cloudflare DC to make sure others were not getting similar 400 errors.
    – Josh Zhang StaffMod
    Commented May 3 at 20:52
  • 4
    @SamGibson if you use developer mode in any of the major browsers it should show you status codes for the images that are loaded. 404, not found of course. 403 is Cloudflare blocking the traffic for a number of reasons one being Hotlink Protection. 400 is a bad request error which is what's happening in this post.
    – Josh Zhang StaffMod
    Commented May 3 at 20:56
  • 1
    Also, status-norepo doesn't seem correct. You've been able to confirm the presence of the behaviour using your logs, which is about as close as you can get to reproducing network issues like this (short of remoting in, or physically travelling to the site experiencing the issue). status-declined or status-deferred seems more appropriate to me (depending on whether you intend to allocate more resources to the investigation at a later date).
    – wizzwizz4
    Commented May 3 at 22:26
  • 4
    @wizzwizz4 Tbh [status-norepro] was my recommendation, and I still think it's correct. While we can see that the issue took place, we aren't able to reproduce the issue, and do not have the ability to diagnose a root cause (yet, generously, but we would need more information - status tags are not necessarily permanent). It's sort of tangential to the post, though, happy to chat about it in another place if you've got curiosities
    – Slate StaffMod
    Commented May 3 at 22:42
  • 1
    Practically - if OP has the issue at two different locations on the same ISP as per the question - are they both getting error 400 or only one of the sites? If that's the case (or the ISP's got something in front that makes both his IPs look the same, and mangles things) that might explain things. Else, from talking to the OP on chat, he seems confused about the whole "you're the only user who seems to be having this" Commented May 4 at 15:01
  • 1
    @JoshZhang, I am getting status 400 for the images when I check it from developer console on Firefox or Chrome. Sorry for late response, I only read all comments now. My internet provider is quite standard, most popular in my country, standard home plan... I have absolutely no idea what I should do to be able to use Stack Exchange sites normally... :/ Commented May 14 at 18:32
  • 4
    I get the same problem too. Images from this answer are not embedded as expected within the SO answer, nor can I see anything when clicking the url. In this case it's https://i.sstatic.net/oTim1caA.jpg and https://i.sstatic.net/rEH9nMck.jpg and I get the oh no error message with RayID of 8855e6f469f209cd and 8855e408491809cd, respectively.
    – Emman
    Commented May 17 at 19:08
  • 8
    I have exactly the same issue too. Images are neither loading at home (fiber from Telia, one of Sweden's major telecom companies) nor at work (via Linköping University's eduroam wifi, tried with two different laptops). But after viewing the page via my mobile phone's 4G network, the images load just fine. Here are a few RayID's from "oh no, that request didn't look right" messages that I'm getting right now: 88742cc2ab6309b0, 88742cc7daeb09b0, 88742cd339f909b0, 88744286988d991b. Commented May 21 at 11:37
  • 1
    @HansLundmark Also broken from telenor: traceroute to i.sstatic.net (, 30 hops max, 60 byte packets 1 _gateway ( 0.167 ms 0.246 ms 0.319 ms 2 ti3226a430.ti.telenor.net ( 4.455 ms 4.485 ms 4.513 ms 3 ti3001c360-ae76-0.ti.telenor.net ( 5.165 ms 5.193 ms 5.218 ms 4 ti3002b400-ae4-0.ti.telenor.net ( 5.036 ms 5.064 ms 5.090 ms 5 netnod-ix-ge-a-sth-1500.cloudflare.com ( 36.646 ms 36.666 ms 36.692 ms 6 ( 5.862 ms 4.875 ms 4.841 ms
    – user877329
    Commented May 31 at 19:21
  • 1
    Any news with this problem? Commented Jun 6 at 6:28
  • 1
    Same issue on another Swedish ISP: traceroute: Warning: i.sstatic.net has multiple addresses; using traceroute to i.sstatic.net (, 64 hops max, 40 byte packets 1 (, 2 (, 3 stb-core-1-et112.net.comhem.se (213.XXX.XXX.XX), 4 ssol1-core-2.bundle-ether2.tele2.net (91.XXX.XX.X), 5 sk1-peer-1.ae2-unit0.tele2.net (91.XXX.XX.XXX), sk1-peer-1.ae1-unit0.tele2.net (91.XXX.XX.XXX), 6 * * *, 7 (, Ray ID from today: 89308b4ba9cf2d62 Commented Jun 13 at 8:12
  • 3
    The images are not working for me neither, It worked around 4 months ago but it stopped. It is very inconvinient since I do not have access to another site therefore I can not see and help, after 2 days I had to install a vpn to be able to see them, I have no idea if it works in the long run, but running a vpn just to see images is too much.
    – amar
    Commented Jul 6 at 14:53

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .