Trouble with one PHP site not loading images

Hey everyone,

Having a bit of trouble getting Caddy to correctly proxy to an Alltube DL page I have set up. If I access the page on LAN, it works fine, and if I set up a forward to access it directly from the web it also works fine.

However, when proxying it through Caddy, it doesn’t load the images or CSS or anything on the page, I just get a blank white page with generic text.

This is what the section of my Caddyfile originally looked like, and this works fine with most of my other pages which are all also proxying through non-standard ports:

https://mydomain.net:555
{
proxy / http://192.168.2.5/ {
transparent
}
tls /etc/letsencrypt/live/mydomain.net/fullchain.pem /etc/letsencrypt/live/mydomain.net/privkey.pem
}

However, with this one, I get the above problem. I did determine what the issue actually was. If I click on the unloaded image and get the URL, it tries to load mydomain.net/img instead of mydomain.net:555/img. So, I removed transparent, and now I at least get the header image to load, but nothing else on the page does, so presumably it’s still not loading something, like CSS, but I’m not sure how to troubleshoot this.

It may be relevant (I don’t know) that the header image, without transparent included, does load, but it loads as an http link rather than https.

I setup an error.log but it never wrote anything to it. The default page for Alltube DL is just index.php, not sure if it’s an issue with that or my Caddy configuration.

So Alltube is just a PHP site?

What web server is running at http://192.168.2.5/?

Hey Matthew,

This site is being served by Apache.

Hi @vincentp,

I suspect the issue is more likely to be in your Apache configuration.

I built a PHP container to the specs required by Rudloff/alltube and ran the PHP site directly off Caddy. My working configuration looks like this:

example.net:555 {
  root /srv/alltube
  gzip
  fastcgi / php:9000 php
  rewrite {
    to {uri} {uri}/ index.php?{query}
  }
}

The site seemed to function as expected, complete with Automatic HTTPS.

Normally when setting up an app like this I would post a link to a live working demonstration, but given the opportunity for public abuse, I’ve decided against it this time.

Hey Matthew,

Thank you for the advice. Turns out the problem was not with Caddy as you suggested. I moved Caddy to another VM and it works fine from there, so I believe this was a firewall issue or something on the VM that was previously running the Caddy server.

1 Like

This topic was automatically closed 90 days after the last reply. New replies are no longer allowed.