# X-Forwarded-For proxy tag not recognized by Discourse?
**URL:** https://meta.discourse.org/t/x-forwarded-for-proxy-tag-not-recognized-by-discourse/77961
**Category:** Self-hosting
**Created:** [January 13, 2018, 10:35pm UTC](https://meta.discourse.org/t/x-forwarded-for-proxy-tag-not-recognized-by-discourse/77961 "2018-01-13T22:35:45Z")
**Posts on this page:** 12
**Page:** 1
### Author:  [@Anil\_Gupta](https://meta.discourse.org/u/Anil_Gupta)
#### Post date: [January 13, 2018, 10:35pm UTC](https://meta.discourse.org/t/x-forwarded-for-proxy-tag-not-recognized-by-discourse/77961/1 "2018-01-13T22:35:46Z")
**Our Set Up**
1. Discourse is installed on Google Compute VM machine with no SSL certificates on this server.
**Force\_https** discourse setting is set to true (checked to force https).
2. We have the front end running with ‘Google Load Balancer’ with **HTTPS certificate** attached at Load balancer level.
3. Google Oauth credentials settings has both **http** and **https** callback URL’s set up.
4. User Request [HTTPS.www.truvisa.com](http://HTTPS.www.truvisa.com) → Google Load balancer **→ HTTP** Discourse on Google Compute engine.
- The [https://www.truvisa.com](https://www.truvisa.com) URL works fine.
- User tries to log-in with Google OAuth. Works fine and user is logged in.
**Problem:**
User Request **HTTP** → Google Load balancer → **HTTP** Discourse on Google Compute engine.
The **[http://www.truvisa.com](http://www.truvisa.com)** url works fine. We actually expected this to be redirected to HTTPs (as we have force https enabled), but it did not work.
- User tries to log-in with Google OAuth. User cannot log-in.
- CSRF error is thrown by Google o-Auth
- 
**What we think is happening:**
I searched through the discourse forum for a solution and understand that Google load balancer (a proxy in our case) need to send the **X-Forwarded-Proto** header for discourse to redirect the http request to https version.
Google load balancer does send this **X-Forwarded-Proto** to discourse installation server.
**My question:**
Is there anything that needs to be changed in Discourse set up anywhere to make this work?
Are we missing any kind of redirection from **http to https** setting in default discourse install?
Please help.
---
### Author:  [@mpalmer](https://meta.discourse.org/u/mpalmer)
#### Post date: [January 13, 2018, 11:28pm UTC](https://meta.discourse.org/t/x-forwarded-for-proxy-tag-not-recognized-by-discourse/77961/2 "2018-01-13T23:28:09Z")
Probably the list of trusted IP addresses in nginx needs to be updated so it’ll trust the XFF and XFP headers that the GAE load balancer is sending.
---
### Author:  [@Anil\_Gupta](https://meta.discourse.org/u/Anil_Gupta)
#### Post date: [January 13, 2018, 11:29pm UTC](https://meta.discourse.org/t/x-forwarded-for-proxy-tag-not-recognized-by-discourse/77961/3 "2018-01-13T23:29:45Z")
Can you please elaborate on where I can add those IP addresses with respect to Discourse installation?
---
### Author:  [@riking](https://meta.discourse.org/u/riking)
#### Post date: [January 14, 2018, 12:43am UTC](https://meta.discourse.org/t/x-forwarded-for-proxy-tag-not-recognized-by-discourse/77961/4 "2018-01-14T00:43:24Z")
Take a look at the `templates/cloudflare.template.yml` file. Basically, you need to insert `set_real_ip_from` directives for the full list of load balancer IPs.
---
### Author:  [@Anil\_Gupta](https://meta.discourse.org/u/Anil_Gupta)
#### Post date: [January 16, 2018, 3:41pm UTC](https://meta.discourse.org/t/x-forwarded-for-proxy-tag-not-recognized-by-discourse/77961/5 "2018-01-16T15:41:51Z")
Thanks Kane for your help, but the primary problem is something else.
After further analysis, I think what we need is **this redirection rule** on Discourse Nginx config:
```
server {
listen 80;
server_name www.example.org;
if ($http_x_forwarded_proto != "https") {
rewrite ^(.*)$ https://$server_name$REQUEST_URI permanent;
}
}
```
This is because if the User is on HTTPS url and tries to log in with Google OAuth, it works fine. So, our primary problem is only related to redirection of http to https domain always.
I tried adding the above rule to **app.yml** file inside **after\_web\_config** and rebuild. It, then shows the nginx welcome screen
## Our app.yml file’s content
```
after_web_config:
- replace:
filename: /etc/nginx/nginx.conf
from: /sendfile.+on;/
to: |
server_names_hash_bucket_size 64;
sendfile on;
- replace:
filename: /etc/nginx/conf.d/discourse.conf
from: /server.+{/
to: |
server {
listen 80;
server_name www.truvisa.com;
if ($http_x_forwarded_proto != "https") {
rewrite ^(.*)$ https://$server_name$REQUEST_URI permanent;
}
}
server {
- file:
path: /etc/nginx/conf.d/discourse_redirect_1.conf
contents: |
server {
listen 80;
server_name truvisa.com;
return 301 https://www.truvisa.com$request_uri;
}
```
* * *
**Can you help with right way of adding this http\_x\_forwarded\_proto rule to discourse?**
NOTE: Our discourse installation is still on HTTP server. The SSL certificate is only installed on load balancer server.
---
### Author:  [@Anil\_Gupta](https://meta.discourse.org/u/Anil_Gupta)
#### Post date: [January 19, 2018, 12:07am UTC](https://meta.discourse.org/t/x-forwarded-for-proxy-tag-not-recognized-by-discourse/77961/6 "2018-01-19T00:07:05Z")
No ideas? Nobody has tried this set up?
These days, it is pretty common to have a LOAD balance server (using HTTPS) and then have Discourse or any other software sitting behind on HTTP.
Can anybody guide (if they have successfully tried) as to where the redirection rule can be added in Discourse configuration?
I need this rule to be configured:
```
server {
listen 80;
server_name www.example.org;
if ($http_x_forwarded_proto != "https") {
rewrite ^(.*)$ https://$server_name$REQUEST_URI permanent;
}
}
```
---
### Author:  [@mpalmer](https://meta.discourse.org/u/mpalmer)
#### Post date: [January 19, 2018, 1:11am UTC](https://meta.discourse.org/t/x-forwarded-for-proxy-tag-not-recognized-by-discourse/77961/7 "2018-01-19T01:11:31Z")
Why would you do the redirect there? Do it at the outer layer, where you’re terminating HTTPS.
---
### Author:  [@Anil\_Gupta](https://meta.discourse.org/u/Anil_Gupta)
#### Post date: [January 19, 2018, 1:19am UTC](https://meta.discourse.org/t/x-forwarded-for-proxy-tag-not-recognized-by-discourse/77961/8 "2018-01-19T01:19:59Z")
That’s the problem.
Its a google load balance server and it does not allow doing it at the load balane server.
They advise to manage the http to https redirection using http\_x\_forwarded\_proto at the end server.
I have tried the same thing with Apache server running wordpress and this same rule works in similar set-up.
As a matter of fact, even Amazon’s ELB suggests the same solution.
---
### Author:  [@mpalmer](https://meta.discourse.org/u/mpalmer)
#### Post date: [January 19, 2018, 1:25am UTC](https://meta.discourse.org/t/x-forwarded-for-proxy-tag-not-recognized-by-discourse/77961/9 "2018-01-19T01:25:38Z")
Use a [dedicated redirection container](https://hub.docker.com/r/q4uw/httpredirector/) on cloud load balancers.
---
### Author:  [@Anil\_Gupta](https://meta.discourse.org/u/Anil_Gupta)
#### Post date: [January 19, 2018, 1:27am UTC](https://meta.discourse.org/t/x-forwarded-for-proxy-tag-not-recognized-by-discourse/77961/10 "2018-01-19T01:27:13Z")
Thanks for quick response. I will try it.
---
### Author:  [@system](https://meta.discourse.org/u/system)
#### Post date: [April 10, 2020, 5:23am UTC](https://meta.discourse.org/t/x-forwarded-for-proxy-tag-not-recognized-by-discourse/77961/11 "2020-04-10T05:23:37Z")
---
### Author:  [@riking](https://meta.discourse.org/u/riking)
#### Post date: [April 10, 2020, 6:56pm UTC](https://meta.discourse.org/t/x-forwarded-for-proxy-tag-not-recognized-by-discourse/77961/12 "2020-04-10T18:56:51Z")