How to Open WordPress Site by IP Instead of Domain Name

Problem Statement & Impact

Direct IP access to a WordPress deployment is a fundamental operational requirement during infrastructure migrations, staging validations, emergency disaster recovery, and local-to-remote synchronization routines. However, WordPress relies heavily on uniform resource identifiers (URIs) stored within its database to construct internal links, asset paths, and canonical references. When administrators attempt to query a WordPress backend directly using an IPv4 or IPv6 address—such as http://192.0.2.45/ or http://[2001:db8::ff00:42:8329]/—they frequently encounter catastrophic rendering failures.

The primary driver of these failures is the hardcoded mapping of domain names inside the WordPress options table. By default, the application extracts the siteurl and home parameters from the database during the bootstrapping phase. When a request arrives with a Host header matching an IP address rather than the registered Fully Qualified Domain Name (FQDN), two critical failure modes manifest:

• Asset Path Mismatches: Cascading Style Sheets (CSS), JavaScript files, and media uploads are rendered with absolute URLs pointing to the old or unpropagated domain name. The browser blocks or fails to resolve these resources due to mixed content policies, CORS constraints, or DNS resolution timeouts.
• HTTP Redirect Loops and Authentication Dropouts: Modern security plugins, SSL/TLS enforcement modules, and web application firewalls (WAFs) inspect incoming request headers. If the SSL certificate installed on the web server (such as Nginx, Apache, or OpenLiteSpeed) does not include the IP address in its Subject Alternative Name (SAN) list, the TLS handshake fails. Even if an insecure HTTP connection is forced, WordPress authentication cookies tied to the domain’s security scope are rejected by the browser, logging the administrator out immediately upon redirection to the wp-admin login screen.

From an enterprise security perspective, exposing a raw IP address without access control lists (ACLs) introduces vectors for automated vulnerability scanning, brute-force attacks against administrative interfaces, and denial-of-service (DoS) exploits that bypass content delivery network (CDN) edge caching layers. Site administrators must balance the immediate troubleshooting utility of IP-based routing with robust perimeter security protocols to prevent unauthorized asset discovery.

Root Cause Analysis & Architecture

To understand why direct IP access behaves unpredictably, one must examine the execution lifecycle of an HTTP request within the LEMP or LAMP stack hosting a WordPress installation. When a client types an IP address into a browser, the request bypasses global DNS nameservers and hits the target web server directly via TCP port 80 (HTTP) or port 443 (HTTPS). The web server configuration determines how this request is routed.

In a standard multi-tenant or single-server environment utilizing Nginx, the default server block catches requests that do not explicitly match a defined server_name directive. If no explicit IP-based virtual host is configured, Nginx falls back to the default server block, which may serve a generic placeholder page or misroute the traffic:

server {
    listen 80 default_server;
    listen [::]:80 default_server;
    server_name _;
    return 444; # Drop connection or serve default root
}

If the web server is configured to accept the IP address as a valid host, the request is handed over to the PHP FastCGI Process Manager (PHP-FPM). PHP executes the index.php entry point, which initializes the WordPress core. During the initialization sequence, specifically within wp-includes/default-constants.php and wp-settings.php, the application queries the MySQL or MariaDB database for the siteurl and home options:

define( 'WP_SITEURL', get_option( 'siteurl' ) );
define( 'WP_HOME', get_option( 'home' ) );

Because these constants dictate the base URL for all generated links, any output sent back to the browser contains references to the domain name, not the IP address. Consequently, clicking any link on the IP-accessed page immediately redirects the browser away from the IP address and toward the domain name, stalling the troubleshooting workflow if DNS records remain unpropagated.

Furthermore, database-level serialization adds complexity. Plugins and themes frequently store absolute URLs inside serialized PHP arrays within the wp_options, wp_postmeta, or custom tables. Simple string replacement queries executed via SQL will corrupt these serialized structures by altering string length indicators, leading to fatal PHP errors or corrupted widget settings.

Step-by-Step Implementation & Remediation Guide

Depending on the operational objective—whether temporarily previewing a site during migration or permanently configuring server blocks for direct IP testing—engineers must employ precise technical methodologies.

Method 1: The Local Hosts File Override (Recommended for Migration Testing)

Bypassing the IP address routing limitation altogether by tricking your local operating system into resolving the domain name to the new server IP is the cleanest administrative approach. This preserves SSL certificates, maintains asset paths, and prevents database modifications.

1. Open your terminal or command prompt with administrative privileges.

2. Locate the hosts file based on your operating system:

• Linux / macOS: /etc/hosts
• Windows: C:\Windows\System32\drivers\etc\hosts

3. Append the target server IP address followed by the domain name:

# /etc/hosts entry for migration testing
192.0.2.45 example.com www.example.com

4. Flush your local DNS resolution cache to ensure the operating system adopts the change immediately:

# Linux (systemd-resolved)
sudo systemd-resolve --flush-caches

# macOS
sudo dscacheutil -flushcache; sudo killall -HUP mDNSResponder

# Windows Command Prompt
ipconfig /flushdns

Method 2: Configuring Web Server Virtual Hosts for IP Access

If you must access the application strictly via IP address on a staging or unmanaged VPS environment, you must configure your web server to accept the IP in the server block definitions.

For Nginx, modify your site configuration file (usually located in /etc/nginx/sites-available/) to include the server IP alongside the domain name:

server {
    listen 80;
    listen [::]:80;
    server_name example.com 192.0.2.45;

    root /var/www/html/example;
    index index.php index.html index.htm;

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

    location ~ \.php$ {
        include snippets/fastcgi-php.conf;
        fastcgi_pass unix:/var/run/php/php8.2-fpm.sock;
    }
}

Test the Nginx configuration syntax and reload the service:

sudo nginx -t
sudo systemctl reload nginx

Method 3: Dynamic URL Override via wp-config.php

To prevent database modification during temporary IP troubleshooting, you can hardcode the site URL values directly in your wp-config.php file. This overrides database queries dynamically.

Open wp-config.php and add the following lines just above the /* That's all, stop editing! */ comment block:

define( 'WP_HOME', 'http://192.0.2.45' );
define( 'WP_SITEURL', 'http://192.0.2.45' );

Warning: Leaving these constants defined in wp-config.php will gray out the “WordPress Address (URL)” and “Site Address (URL)” fields in the WordPress Dashboard (Settings > General), preventing accidental overwrites via the UI.

Method 4: Safe Database URL Migration via WP-CLI

If you are transitioning the site permanently to a new IP or server infrastructure and must update the database, avoid naive SQL REPLACE queries that break serialized data. Instead, use WP-CLI:

# Navigate to the WordPress root directory
cd /var/www/html/example

# Perform a dry-run search and replace to verify changes
wp search-replace 'https://old-domain.com' 'http://192.0.2.45' --dry-run

# Execute the search and replace safely handling serialized arrays
wp search-replace 'https://old-domain.com' 'http://192.0.2.45' --all-tables

Production Hardening & Edge Cases

Deploying modifications for IP-based access introduces several security and performance risks in production environments that require careful mitigation.

SSL/TLS Certificate Mismatches: Most commercial Certificate Authorities (CAs) do not issue SSL certificates for raw IP addresses. If your Nginx or Apache server enforces HTTPS, accessing https://192.0.2.45 will trigger severe browser security warnings (NET::ERR_CERT_COMMON_NAME_INVALID). To bypass this during testing, you must either generate a self-signed certificate for the IP address or temporarily configure a secondary HTTP-only server block for troubleshooting.

Caching Layer Invalidation: Reverse proxies such as Varnish, CDN edge caches (Cloudflare), and object caching plugins (Redis/Memcached) cache responses based on the HTTP Host header. If requests are suddenly served via an IP address, cache keys may collide or fail to purge correctly. Always flush your object cache and opcode cache after altering URL parameters:

# Flush WP-CLI cache and object cache
wp cache flush

SEO and Search Engine Indexing: Search engine crawlers discovering your site via an open IP address may index duplicate content or flag the domain for security anomalies. Ensure that IP-based access is protected behind IP whitelists in your firewall or restricted via HTTP Basic Authentication during staging phases:

# Add basic authentication to Nginx IP server block
location / {
    auth_basic "Restricted Access";
    auth_basic_user_file /etc/nginx/.htpasswd;
    try_files $uri $uri/ /index.php?$args;
}

Diagnostic Verification & Checklist

After implementing IP access modifications or hosts file overrides, verify system integrity using the following diagnostic validation matrix:

Monitor system resource allocation using htop or vmstat during initial request loads to confirm that PHP-FPM worker processes do not spike in memory consumption due to unresolved asset loops or missing rewrite rules.