Score:0

Server changes Domain Name to IP in address bar

us flag

I'm no server guru so looking for some assistance. I am hosting a laravel project on a digital ocean droplet, and pointing a subdomain registered at godaddy to said droplet. The address bar is updating to display the server IP rather than the relevant domain when attempting to access the site.

The Domain is split into two parts with the base domain pointing to a wordpress server, and the myaccount subdomain pointing to a digital ocean droplet.

DNS records applied:

CNAME www -> @

A @ -> XX.XXX.XX.XXX

A subdomain -> 184.168.131.241

(automatically set by godaddy when setting forwarding rule to point towards the server at 68.183.26.235, I'm guessing some internal forwarding address).

Server Configurations:

NGINX.conf

user www-data;
worker_processes auto;
pid /run/nginx.pid;
include /etc/nginx/modules-enabled/*.conf;

events {
        worker_connections 768;
        # multi_accept on;
}

http {

        ##
        # Basic Settings
        ##

        sendfile on;
        tcp_nopush on;
        tcp_nodelay on;
        keepalive_timeout 65;
        types_hash_max_size 2048;
        client_max_body_size 120M;
        # server_tokens off;

        # server_names_hash_bucket_size 64;
        # server_name_in_redirect off;

        include /etc/nginx/mime.types;
        default_type application/octet-stream;

        ##
        # SSL Settings
        ##

        ssl_protocols TLSv1 TLSv1.1 TLSv1.2 TLSv1.3; # Dropping SSLv3, ref: POODLE
        ssl_prefer_server_ciphers on;

        ##
        # Logging Settings
        ##

        access_log /var/log/nginx/access.log;
        error_log /var/log/nginx/error.log;

        ##
        # Gzip Settings
        ##

        gzip on;

        # gzip_vary on;
        # gzip_proxied any;
        # gzip_comp_level 6;
        # gzip_buffers 16 8k;
        # gzip_http_version 1.1;
        # gzip_types text/plain text/css application/json application/javascript text/xml application/xml application/xml+rss text/javascript;

        ##
        # Virtual Host Configs

Sites Available: alphamark-client (symlinked to sites-enabled)

server {
    server_name subdomain.example.com;
    root /var/www/alphamark-client/public;

    add_header X-Frame-Options "SAMEORIGIN";
    add_header X-Content-Type-Options "nosniff";

    index index.php;

    charset utf-8;

    location / {
        try_files $uri $uri/ /index.php?$query_string;
    }

    location = /favicon.ico { access_log off; log_not_found off; }
    location = /robots.txt  { access_log off; log_not_found off; }

    error_page 404 /index.php;

    location ~ \.php$ {
        fastcgi_pass unix:/var/run/php/php7.4-fpm.sock;
        fastcgi_param SCRIPT_FILENAME $realpath_root$fastcgi_script_name;
        include fastcgi_params;
    }

    location ~ /\.(?!well-known).* {
        deny all;
    }

    listen 443 ssl; # managed by Certbot
    ssl_certificate /etc/letsencrypt/live/subdomain.example.com/fullchain.pem; # managed by Certbot
    ssl_certificate_key /etc/letsencrypt/live/subdomain.example.com/privkey.pem; # managed by Certbot
    include /etc/letsencrypt/options-ssl-nginx.conf; # managed by Certbot
    ssl_dhparam /etc/letsencrypt/ssl-dhparams.pem; # managed by Certbot

}
server {
    if ($host = subdomain.example.com) {
        return 301 https://$host$request_uri;
    } # managed by Certbot


    listen 80;
    server_name subdomain.example.com;
    return 404; # managed by Certbot


}

Laravel Application Environment:

APP_NAME=AlphamarkClient

APP_ENV=production

APP_DEBUG=false

APP_URL=https://subdomain.example.com

When attempting to access the subdomain, the server can be accessed. However, the address bar updates to reflect the server IP. This also breaks the ssl certificate do to it being registered to the subdomain. Any help with identifying which part of my setup is causing this behavior would be greatly appreciated.

kr flag
It sounds like one or more of the pages is re-directing to a URL that uses the IP address instead of the hostname. This could happen in many different places (server config, web pages, javascript, etc.), so you'll probably want to turn on developer mode in your browser, reproduce the problem, and find out where that happens by tracing through.
sv flag
Welcome to ServerFault. Please turn off php and try to reproduce the issue. If the issue still exists, then the issue is with the web server configuration.
Kyle R avatar
us flag
@PothiKalimuthu I disabled the php7.4-fpm service on my installation, after doing so the domain is still changing to the IP when attempting to load the now-unavailable site
djdomi avatar
za flag
then post please which Webserver you are using and show us the configuration
Paul avatar
cn flag
Your provided NGINX configuration is not the full configuration. Please post using text, not screen caps, the contents of files in `/etc/nginx/sites-available/` symlinked in `/etc/nginx/sites-enabled/`. If you want to replace domains and IP addresses, your post will be easier to read and get better answers if you use domains like example.com, example.net, etc. and IP addresses such as 203.0.113.0/24, 192.0.2.0/24, etc.
Kyle R avatar
us flag
@Paul I had attached that information in a screenshot. I've edited it to include as text and obfuscated the address as suggested
Nikita Kipriyanov avatar
za flag
can you run `curl -I https://...` with any address that changes into IP? Notice "I" is the capital i, that switch makes curl to only print *response headers*. I mean, if there is redirect status (one of 3xx codes), and the `Location` header has the IP address in the URL, this is indeed a redirect. Then you may look into logs and analyze why there was a redirect into this url. By the way, do you have any reverse proxies anywhere in front of your web server?
Paul avatar
cn flag
What happens if you add `fastcgi_param HTTPS on;`?
mangohost

Post an answer

Most people don’t grasp that asking a lot of questions unlocks learning and improves interpersonal bonding. In Alison’s studies, for example, though people could accurately recall how many questions had been asked in their conversations, they didn’t intuit the link between questions and liking. Across four studies, in which participants were engaged in conversations themselves or read transcripts of others’ conversations, people tended not to realize that question asking would influence—or had influenced—the level of amity between the conversationalists.