Problem redirect from another server to Discourse server

(Maximiliano Carvalho) #1


I just start using Discourse and I am trying to get a particular setup running.

I have a main domain: www. which is located at one server and is running Magento application.

I want to serve the Discourse application from www., in order to do that I am trying to set up a proxy using Nginx and some custom configuration with Discourse.

The Discourse application is up and running here: http://
The Discourse was installed in a Digital Ocean droplet, so it’s physically disconnected from the Magento server.

Within the Magento server configuration I did the following:

location /vapecom/ {
    proxy_set_header X-Real-IP $remote_addr;
    proxy_set_header X-Forwarded-For $remote_addr;
    proxy_set_header Host $host;

To enable Discourse under a sub-directory I followed this guide: subfolder-support-with-docker/30507

The problem is that when I try to access the Discourse app typing www. I just see a blank page. I could see that the error is related to the assets that Discourse is trying to load with (for example):

There is anyone who could help me with this?


(Rafael dos Santos Silva) #2

Since you are already using two distinct and separated servers, going with instead of the subfolder will be:

  • easier
  • faster
  • more secure

You can even make the subfolder address redirect you to the correct domain.

(Maximiliano Carvalho) #3

Hi Rafael,

Thanks for your reply.
Unfortunately using a subdomain is not an option. Is not SEO friendly. We need the main domain to get the credits.
I saw lots of others questions about running under a subdirectory and seems that Discourse doesn’t deal well with this type of configuration. Maybe because is using relative links to load the assets, is it possible to change that?

(Felix Freiberger) #4

This is a very famous urban legend, which fortunately doesn’t make it true:

(Maximiliano Carvalho) #5

Hi Felix,

I appreciate your comments and I already took them in consideration.
On the other hand, our marketing staff said the exact opposite together with the numbers.
What Matt said is that is better to have a subdomain instead of having none. So if we are going to play subdomain blog against no blog, then is better to have a subdomain, but this doesn’t mean that’s the same thing, cause is not.
Google will give juice to a subdomain individually, if you want to promote only the main domain, then you need to use subdirectory approach.

Another thing, and please don’t take this personally, but I searched a lot in order to find solutions to my problem, and I saw that there are many many people who need the same setup, and I am always seeing answers like “you should use subdomain” or “Google doesn’t care about the structure”, well, you should stick with the question. If we are looking for a subdirectory structure, that is because we need that structure and not the easy one.

Again, thanks for your help.

(Felix Freiberger) #6

These two lines should probably contain the same URL…

Apart from that, it looks like (right now) your installation is at, not

Once again, this is an urban legend.

Something that’s actually true is that site speed is important for your ranking:

Routing all requests through two remote servers will most likely cost you way more “juice” than not following urban legends…

(Maximiliano Carvalho) #7

Hi Felix,

Thanks again for your reply. I already tried the changes to the proxy_pass and it does not work.
The “problem” lies on Discourse side, they way the assets are being called plus the routing system I think.

About the “urban legend” well, again, it is not urban legend once we have statistics to prove the opposite and no real data to prove that Google does not care about the subdomain/subdirectory.
Just saying that something is not true is not ideal. At the end, the numbers don’t lie.

(Felix Freiberger) #8

The problem is that Discourse is not being served on, but on Fix that first by following the subfolder setup guide.

(Maximiliano Carvalho) #9

Hi Felix,

As I said, I already tried that configuration, it’s not working.
You are probably trying to access now, and now the configuration is another. We can’t afford not having the service working so we moved to a subdomain configuration.
At the moment that I posted my question, the configuration was as I said in the beginning, and wasn’t working. The Discourse home page was loaded all blank, and inspecting the assets I could see that they were with a 404 status (not found).
That’s because the assets are loading with relative paths, so <script src="/assets/locales/en-afffd4b459a9e49d5c58641702e623f2bbcb2f6c320e4616b45432301b4e256a.js"></script>

The Dockerized Nginx is not able to resolve the path when using subfolders and a proxied connection coming from another server, once the assets are within the public directory and not inside the /vapecom sub-directory.
So, this is not wrong or right, is just made for a setup with dedicated domain or subdomain.
If I use a simple Wordpress inside the subdir it will work, as any other tool like Statamic, OctoberCms, etc.

(Felix Freiberger) #10

Did you test that through your proxy, or by accessing

(Maximiliano Carvalho) #11


Yes, I tested using many different configurations, including this one.

(Felix Freiberger) #12

In that case, I can only recommend that you take a very close look at the documentation:

Many users have followed this howto and got a working install, so the instructions should be sound.
I can’t offer you any additional help until Discourse is served correctly from as I’ve never set up a subfolder install myself.

(Maximiliano Carvalho) #13


I am rebuilding again, with changed configurations.

Here is what I included:

    - exec:
        cd: $home
          - mkdir -p public/vapecom
          - cd public/vapecom && ln -s ../uploads && ln -s ../backups
    - replace:
       global: true
       filename: /etc/nginx/conf.d/discourse.conf
       from: proxy_pass http://discourse;
       to: |
          rewrite ^/(.*)$ /vapecom/$1 break;
          proxy_pass http://discourse;
    - replace:
       filename: /etc/nginx/conf.d/discourse.conf
       from: etag off;
       to: |
          etag off;
          location /vapecom {
             rewrite ^/vapecom/?(.*)$ /$1;
    - replace:
         filename: /etc/nginx/conf.d/discourse.conf
         from: $proxy_add_x_forwarded_for
         to: $http_fastly_client_ip
         global: true

Now we just need to wait for the end of the rebuild process

(Maximiliano Carvalho) #14

All set now.

The /vapecom subdir is up and running and the Nginx proxy (on my external server) is set to:

location /vapecom/ {
    proxy_set_header X-Real-IP $remote_addr;
    proxy_set_header X-Forwarded-For $remote_addr;
    proxy_set_header Host $host;

So, my main domain is:
The other server have a Nginx proxy to:
The way that it should work is:

(Felix Freiberger) #15

Okay, it looks like your install is working fine on So the subfolder install does work fine after all :thumbsup:

Proxying is the problem, so this is an nginx configuration issue. There are 404s for URLs like this one:

The direkt URL works, so Discourse isn’t part of the problem.

I’m not an nginx expert, but I feel that the proxy_pass URL should end with a slash. If this doesn’t help, try looking into nginx’s logs.

(Maximiliano Carvalho) #16


As I said, it works for other applications. And again, this is a thing related to the way Discourse app is configured regarding the Nginx routes.
The proxy_pass is just, as it says, a proxy, just send request from one end to another.
The final end (Discourse) should handle the requests and resolve links.

(Felix Freiberger) #17

And it does that wonderfully, see here:

However, your nginx proxy is somehow proxying the requests incorrectly.

(Felix Freiberger) #18

Oh, and if you had followed my suggestion, it would actually work:

I literally just copy-and-pasted your snipped into my nginx config, appended the slash, and reloaded nginx’s config.

(Maximiliano Carvalho) #19

Well, you Nginx is placed in the same saver I think.
With the domain at the same server.
The only think that I know is that the Nginx (on my external server) just proxy to the request.

Thanks for your help anyway, this is becoming too high cost.

(Felix Freiberger) #20

No? I literally just set up my server to proxy to your server.

Your installation is down right now, but if it were up, you’d actually see your install being served behind my nginx on my domain here, which is exactly the setup you wanted?

That’s what @Falco has been warning you about in the beginning.

I find it highly curious that you then actually follow though with it until you are literally one slash away from a working site, and than back out ¯\_(ツ)_/¯