Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Trouble with FrankenPHP in worker mode behind load balancer #1219

Open
dfsoeten opened this issue Dec 3, 2024 · 5 comments
Open

Trouble with FrankenPHP in worker mode behind load balancer #1219

dfsoeten opened this issue Dec 3, 2024 · 5 comments

Comments

@dfsoeten
Copy link

dfsoeten commented Dec 3, 2024

Hey all!

Currently I'm trying to setup FrankenPHP for my Shopware application after having great success with it in other Symonfy based applications. Everything works as expected when not using the worker mode.

After installing the FrankenPHP runtime and setting the FRANKENPHP_CONFIG to worker ./public/index.php and APP_RUNTIME to Runtime\\FrankenPhpSymfony\\Runtime the Symfony\Component\Routing\Generator\UrlGenerator generates HTTP urls instead of the HTTPS urls.

Showpare itself seems to already utilze the Symfony runtime component but usally does so using Caddy + PHP FPM. My public/index.php file is identical to the one being used here.

After thoroughly consulting Symfony's docs about configuring my Shopware application behind a load balancer, I am still unable to figure out exactly why the generated urls are using HTTP only when using FrankenPHP's worker mode. I have debugged locally to confirm that Shopware's kernel is acutally passed into the FrankenPHP runtime.

I've also made sure that my application receives the X-Forwarded-For and X-Forwarded-Proto headers by the Google Cloud Load Balancer.

Some help would be greatly appriciated!

@7-zete-7
Copy link

7-zete-7 commented Dec 3, 2024

Hi @dfsoeten!

I encountered the same problem today.
Thank you very much! Your message helped me start digging in the right direction.

In my case, the problem was in Caddy not trusting the proxies above (see https://caddyserver.com/docs/caddyfile/directives/reverse_proxy#defaults).
Adding the trusted_proxies option solved the problem. It might be a solution for you too.

@dfsoeten
Copy link
Author

dfsoeten commented Dec 4, 2024

Hey, thanks for your reply.

I don't see how this solves the issue. Primarly because FrankenPHP works as expected when not running in worker mode. To me it seems that confirms my configuration (FrankenPHP, Google Cloud LB, Symfony) have been configured properly.

Just in case I gave it a shot by configuring the following environment variable: CADDY_GLOBAL_OPTIONS and set it to servers { \n trusted_proxies static private_ranges \n } to trust all private ranges as per Caddy docs. This doesn't solve my issue.

Thanks regardless for your input! I'm open to any further ideas.

@wiseguy1394
Copy link

@dfsoeten any progress on this? We experiencing same behaviour for our symfony application.

@dfsoeten
Copy link
Author

@wiseguy1394 no I haven't managed to figured out the root cause as of yet.

@vdwijngaert
Copy link

As you mentioned google cloud loadbalancer, did you check https://cloud.google.com/load-balancing/docs/https#target-proxies?

Maybe the IP addresses used internally by the loadbalancer might not be in the default private ranges? ie, it mentions this:

When running HTTP reverse proxy software on the load balancer's backends, the software might append one or both of the following IP addresses to the end of the X-Forwarded-For header:

The IP address of the Google Front End (GFE) that connected to the backend. These IP addresses are in the 130.211.0.0/22 and 35.191.0.0/16 ranges.

The IP address of the backend system itself.

Not sure if these are the actual IPs used by the thing that actually connects to your frankenphp, but might be worth checking whether these IPs are actually matching your trusted_proxies rule.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

4 participants