I’m hosting a Rails application, personal site and personal blog on the same droplet. Whenever I go to blog.mysite.com I get the Rails site rather than the Ghost blog.

There are a few posts already detailing Ghost on subdomains with Nginx server blocks but I haven’t had much success and I think it may be because of the nature of my setup.

I’m running a Rails application with passenger, it works and everything is fine there.
The DNS records for my personal site are Digital Ocean but the site itself is Github.io. So www.mysite.com has a CNAME of mysite.github.io

Now I am trying to set up a Ghost blog on blog.mysite.com.

I have an A record for a blog that points to my droplet’s IP. I have a blog.mysite.com server block (the one that Ghost creates for you). But whenever I go to blog.mysite.com I get my Rails application mentioned above.

I’m wondering if this is an Nginx issue, a DNS issue or something else I’m missing.

These answers are provided by our Community. If you find them useful, show some love by clicking the heart. If you run into issues leave a comment, or add your own answer to help others.

Submit an Answer
2 answers

Hi @tfantinaStarfish,

The way you’ve described it, I can confirm this is not a DNS issue but an Nginx one. Most probably somewhere in the config file something is missing and thus redirecting you to your main website. Can you please provide us with the Nginx configuration file for blog.mysite.com so that I can see if everything has been configured properly?


  • Hey, thanks for the response @KFSys. I have two server blocks in sites-available linked in sites-enabled at the moment:

    This is my server block for the rails_site (the one that works but is also where my subdomain blog.mysite.com is pointing).

    server {
            server_name rails_site.com www.rails_site.com;
        listen 80 default_server;
        listen 443 ssl;
        if ($scheme != "https") {
            return 301 https://rails_site.com$request_uri;
        if ($host = www.ciaoplace.com) {
            return 301 https://rails_site.com$request_uri;
            root /srv/rails_site/current/public;
            passenger_enabled on;
            passenger_app_env production;
            passenger_force_max_concurrent_requests_per_process 0;
            client_max_body_size 40m;
            location ~ ^/(assets|packs) {
                    expires max;
                    gzip_static on;
       # certbot stuff (paths modified when posted here)
        ssl_certificate path/fullchain.pem; # managed by Certbot
        ssl_certificate_key privkey.pem; # managed by Certbot

    The second was generated by Ghost when I installed it on the server:

    server {
        listen 80;
        listen [::]:80;
        server_name blog.mysite.com;
        root /srv/blog/system/nginx-root; # Used for acme.sh SSL verification (https://acme.sh)
        location / {
            proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
            proxy_set_header X-Forwarded-Proto $scheme;
            proxy_set_header X-Real-IP $remote_addr;
            proxy_set_header Host $http_host;
        location ~ /.well-known {
            allow all;
        client_max_body_size 50m;

As it turns out it was an issue with my certificate, I was not aware that a misconfigured certificate would cause a redirect to the default server but this was the case. I used the default certificate that the Ghost install gives you the option of creating but for whatever reason, it did not work. I ran a certbot –nginx for the subdomain and everything started working!