IMX.to - support

[IMX]

Sorry guys, cloudflare has issue, we made solution and it works for now

[viper37]

Sorry guys, cloudflare has issue, we made solution and it works for now

Good news

[Doran]

Sorry guys, cloudflare has issue, we made solution and it works for now

Still getting 404 errors on actual images, but thumbnails work perfectly. Imx.to homepage also alternates between 403 and 404 errors when trying to access it.

[mike=)).]

The imx.to homepage is currently giving a "403 forbidden" error | nginx.

Something to fix on the server side, I think.

https://stackoverflow.com/questions/16808...03-forbidden

[evenings]

...yeah, imx.to is def wonky today. Uploaded fine after a couple of hiccups and farts. But nada on the thumbs ...sigh.😬

[roger33]

The thumbnails and images are there. You can check it by manually rewriting the imx.to image links. Looks like they have an issue with redirection.

image being loaded on image page: https://imx.to/u/i/2025/04/11/62ibba.jpg
image physical location: https://i.imx.to/i/2025/04/11/62ibba.jpg

All images are online, IMX guys just need to fix their code to display them properly. In the meantime, be patient and check other stuff. There are billions of images here

[aletheon19]

In the meantime, be patient and check other stuff. There are billions of images here

But half (my guess) of them are stored on IMX.to

It would actually be interesting to see the actual statistics of image links distribution per filehost - maybe admins can get it (at least for the last year). Probably pixhost.to is second and vipr.im is third.

[Progishness]

But half (my guess) of them are stored on IMX.to

It would actually be interesting to see the actual statistics of image links distribution per filehost - maybe admins can get it (at least for the last year). Probably pixhost.to is second and vipr.im is third.

That sounds like a job for Twatty.

[fuckthename]

Is imx.to still down?

[Progishness]

Is imx.to still down?

Yup.

[IMX]

Sorry guys but cloudflare has billing problem www.cloudflarestatus.com

and until they solve, we keep problem

[IMX]

we work on solution but images etc work now, uploads too

[mike=)).]

Problems are the meaning of life. If there were no problems then there would be no evolution. Homo Sapiens did not make axes for nothing. I prefer to think of problems as challenges, and challenges help to keep your mind fit. Having said that, there remains one issue: how to transfer knowledge to the next generation? I would happily download my mind to an external HD to pass on to my siblings. Maybe one day that might be possible, maybe put my brain in cold storage until that day? Can you restore a brain? They have found entire mammoths frozen in permafrost in Siberia. I wonder what they would think of elephants.

[evenings]

...prolly wonder why the elephants are running about naked, but that's just an uninformed opinion.

[NAC30]

Hello,
for me some posts with IMX.to images won’t download in VRipper, like this Nicole Peters post. It displays alright on the VG webpage and on IMX.to, but in the VRipper I get the following error (i.e. from the 3rd try):

Failed to download http://imx.to/img-55ae48b0ded9b.html: #3 tries failed
------------
me.vripper.exception.DownloadException: org.apache.hc.core5.http.NoHttpResponseException: The target server failed to respond
	at me.vripper.services.DownloadService$ImageDownloadRunnable.download(DownloadService.kt:128)
	at me.vripper.services.DownloadService$ImageDownloadRunnable.run(DownloadService.kt:178)
	at dev.failsafe.Functions.lambda$toCtxSupplier$9(Functions.java:228)
	at dev.failsafe.Functions.lambda$getPromise$1(Functions.java:83)
	at dev.failsafe.Functions.lambda$toAsync$8(Functions.java:195)
	at dev.failsafe.internal.RetryPolicyExecutor.handleAsync(RetryPolicyExecutor.java:145)
	at dev.failsafe.internal.RetryPolicyExecutor.lambda$handleAsync$2(RetryPolicyExecutor.java:170)
	at dev.failsafe.internal.util.DelegatingScheduler.lambda$schedule$0(DelegatingScheduler.java:141)
	at java.base/java.util.concurrent.FutureTask.run(Unknown Source)
	at java.base/java.lang.VirtualThread.run(Unknown Source)
Caused by: org.apache.hc.core5.http.NoHttpResponseException: The target server failed to respond
	at org.apache.hc.core5.http.impl.io.DefaultBHttpClientConnection.receiveResponseHeader(DefaultBHttpClientConnection.java:333)
	at org.apache.hc.core5.http.impl.io.HttpRequestExecutor.execute(HttpRequestExecutor.java:193)
	at org.apache.hc.client5.http.impl.classic.InternalExecRuntime.lambda$execute$0(InternalExecRuntime.java:236)
	at org.apache.hc.client5.http.impl.io.PoolingHttpClientConnectionManager$InternalConnectionEndpoint.execute(PoolingHttpClientConnectionManager.java:791)
	at org.apache.hc.client5.http.impl.classic.InternalExecRuntime.execute(InternalExecRuntime.java:233)
	at org.apache.hc.client5.http.impl.classic.MainClientExec.execute(MainClientExec.java:121)
	at org.apache.hc.client5.http.impl.classic.ExecChainElement.execute(ExecChainElement.java:51)
	at org.apache.hc.client5.http.impl.classic.ConnectExec.execute(ConnectExec.java:199)
	at org.apache.hc.client5.http.impl.classic.ExecChainElement.execute(ExecChainElement.java:51)
	at org.apache.hc.client5.http.impl.classic.ProtocolExec.execute(ProtocolExec.java:192)
	at org.apache.hc.client5.http.impl.classic.ExecChainElement.execute(ExecChainElement.java:51)
	at org.apache.hc.client5.http.impl.classic.ContentCompressionExec.execute(ContentCompressionExec.java:150)
	at org.apache.hc.client5.http.impl.classic.ExecChainElement.execute(ExecChainElement.java:51)
	at org.apache.hc.client5.http.impl.classic.RedirectExec.execute(RedirectExec.java:110)
	at org.apache.hc.client5.http.impl.classic.ExecChainElement.execute(ExecChainElement.java:51)
	at org.apache.hc.client5.http.impl.classic.InternalHttpClient.doExecute(InternalHttpClient.java:174)
	at org.apache.hc.client5.http.impl.classic.CloseableHttpClient.execute(CloseableHttpClient.java:245)
	at org.apache.hc.client5.http.impl.classic.CloseableHttpClient.execute(CloseableHttpClient.java:188)
	at me.vripper.host.Host.head(Host.kt:158)
	at me.vripper.host.Host.downloadInternal(Host.kt:57)
	at me.vripper.services.DownloadService$ImageDownloadRunnable.download(DownloadService.kt:103)
	at me.vripper.services.DownloadService$ImageDownloadRunnable.run(DownloadService.kt:178)
	at dev.failsafe.Functions.lambda$toCtxSupplier$9(Functions.java:228)
	at dev.failsafe.Functions.lambda$getPromise$1(Functions.java:83)
	at dev.failsafe.Functions.lambda$toAsync$8(Functions.java:195)
	at dev.failsafe.internal.RetryPolicyExecutor.handleAsync(RetryPolicyExecutor.java:145)
	at dev.failsafe.internal.RetryPolicyExecutor.lambda$handleAsync$2(RetryPolicyExecutor.java:170)
	at dev.failsafe.internal.util.DelegatingScheduler.lambda$schedule$0(DelegatingScheduler.java:141)
	at java.base/java.util.concurrent.FutureTask.run(Unknown Source)
	at java.base/java.lang.VirtualThread.run(Unknown Source)

Newer posts with IMX images download alright. It may have something to with a change in the URL on IMX. For those threads that show errors, the URL is built like that https://imx.to/img-55ae47cd06846.html - on threads that down VRipper can download it’s like that: https://imx.to/i/4ry0k0.

P.S. I used 6.5.2 on a Windows 11 machine.