Reverse Proxy Not Working

I tried reverse proxy on Caddy 2. Why is this not working?

reverse_proxy /wp-includes/* d1ynnfmvgy6pnn.cloudfront.net
reverse_proxy /wp-content/* d1ynnfmvgy6pnn.cloudfront.net

Didn’t work from this way too:

reverse_proxy /wp-includes/* d1ynnfmvgy6pnn.cloudfront.net:443
reverse_proxy /wp-content/* d1ynnfmvgy6pnn.cloudfront.net:443

Please help.
Thanks!

What is not working?

Please fill out the topic template so we can help you. Deleting it when you make a new post isn’t going to help us help you.

2 Likes

Sorry about that matt! I mean to say when I reverse proxy:

/wp-includes/* and /wp-content/* in that way,

The website shows 500 server error for items on those directories. Then none of them displays on the webpage. That’s how reverse proxy is not working.

500 series errors imply an issue connecting upstream.

Most commonly this is due to misconfiguration, either in Caddy or in the upstream server itself.

Without more information, I hesitate to speculate further; there’s too many possibilities to simply enumerate all the ways something could be going wrong.

2 Likes

Caddy configuration is valid as well as upstream is also working. I checked.

I also tried with Alias record on subdomain but still the files on those directory shows 500 server error.

Also, when I point my root domain to Alias of CDN, everything functions correctly. Only the reverse proxy shows 500 server error.

Reverse proxying functions fine for me on Caddy v2.0.0.

With an arbitrary subfolder and arbitrary upstream, I’m able to get a working response via reverse proxy.

If you don’t want to give us any of the information on a help template, all I can do is suggest that perhaps your own troubleshooting efforts should be directed at emulating the kind of requests Caddy would be making, perhaps via curl commands run from the Caddy host, and inspecting that side of the process (Caddy <-> upstream HTTP communication) manually.

2 Likes

@Whitestrake here is the full code:

example1.com, www.example1.com, cdn.example1.com {
tls /etc/letsencrypt/live/example1.com/fullchain.pem /etc/letsencrypt/live/example1.com/privkey.pem
root * /var/www/html/example2
reverse_proxy /wp-includes/* d1yhnfmvgy6pnn.cloudfront.net
reverse_proxy /wp-content/* d1yhnfmvgy6pnn.cloudfront.net
php_fastcgi unix//var/opt/remi/php74/run/php-fpm/www.sock
encode gzip
file_server
header Strict-Transport-Security max-age=7884000
@static {
file 
path *.ico *.css *.js *.gif *.jpg *.jpeg *.png *.svg *.woff *.woff2
}
header @static Cache-Control max-age=7884000
log {
output file /var/log/caddy/example1.log
format console
}
}

And, that gave me 500 server error on reverse proxy while CloudFront is working fine even on Alias record as you can check as on example below:

https://d1yhnfmvgy6pnn.cloudfront.net/wp-content/uploads/2020/01/that_work_fast.png
https://www.thatworkfast.com/wp-content/uploads/2020/01/that_work_fast.png

I just didn’t wanted to post my website link in public. So, that’s why I didn’t provided all the information before.

Kindly

Even this returns error on browser if I do:

@static {
file 
path *.ico *.css *.js *.gif *.jpg *.jpeg *.png *.svg *.woff *.woff2
}
reverse_proxy @static d1yhnfmvgy6pnn.cloudfront.net

I noted that in your original post, the hostname is d1ynnfmvgy6pnn.cloudfront.net, which has no A records and naturally produces errors for me too, specifically Status 502, when I try to reverse proxy to it.

I tested with the hostname you’ve posted most recently, d1yhnfmvgy6pnn.cloudfront.net, and got a good result:

~/Projects/test
➜ caddy version
v2.0.0 h1:pQSaIJGFluFvu8KDGDODV8u4/QRED/OPyIR+MWYYse8=

~/Projects/test
➜ cat Caddyfile
www.thatworkfast.com {
  tls internal
  reverse_proxy /wp-content/* d1yhnfmvgy6pnn.cloudfront.net:443
}

~/Projects/test
➜ curl -IL https://www.thatworkfast.com/wp-content/uploads/2020/01/that_work_fast.png --resolve www.thatworkfast.com:443:127.0.0.1
HTTP/2 200
accept-ranges: bytes
age: 2164
cache-control: max-age=15552000
content-type: image/png
date: Tue, 12 May 2020 07:14:36 GMT
etag: "q4cdd114q5"
last-modified: Sun, 19 Jan 2020 06:43:49 GMT
server: Caddy
server: Caddy
strict-transport-security: max-age=15552000
via: 1.1 1c65a9672d4009a4b2d2b0463141bfa7.cloudfront.net (CloudFront)
x-amz-cf-id: xGVZRVRieLIRhEeZ3D75FYpPh4hdX9k3iLcylOKEn_4hpuU3Ujf4-g==
x-amz-cf-pop: SYD1-C1
x-cache: Hit from cloudfront
content-length: 52781

I told you that I didn’t wanted to post my original URL at first. Now, its gone too far so I had to post my original URL in public.

Anyway, I will try to sort this out myself. Thank you!

Good luck!

I am sorry about before. It was my mistake and it is working now. What I did was I also reverse_proxy cdn fetching origin url. So, cdn got the problem in loading those files since they were fetched from cdn to cdn not from server to cdn. My apologies.

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