### Problem
There's the [new image hosting system][1] and Super User (my main "playground") [is trialling it][2].
My problem is I cannot see images hosted on `i.sstatic.net`. This is how it looks like:
[![placeholder instead of an image][3]][3]
This particular screenshot is from the following question: [*USB-C Splitter for external SSD enclosure*][4]. 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][5]][5]
`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)... 104.18.41.33, 172.64.146.223
Connecting to i.sstatic.net (i.sstatic.net)|104.18.41.33|: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 172.64.146.223:443
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.
---
### Details
- *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 `213.5.145.0/24` 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][6]).
- 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 `172.64.146.223` or to `104.18.41.33`. 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.
---
### Hypothesis
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.
0. A request from *B* ultimately goes to the same or to another server that serves the resource to the IP address of *B* successfully.
0. The resource gets copied to a node (or cache) closer to *B* automatically.
0. It so happens this node (or cache) is the best choice when *A* requests the resource again.
0. 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.
[1]: https://meta.stackexchange.com/q/395024/355310
[2]: https://meta.superuser.com/q/15188/432690
[3]: https://i.sstatic.net/5BIW2.png
[4]: https://superuser.com/q/1838284/432690
[5]: https://i.sstatic.net/JTrci.png
[6]: https://askubuntu.com/q/1509671/693277