Stop port # from being added to URL after WordPress admin login?

theboyk

I'm migrating a handful of WordPress sites from MAMP Pro to Indigo. Having an issue where, after sucessfully logging into the WordPress admin dashboard, the site's HTTPS port is being added to the URL.

Has anyone run into this? Any ideas how I can get the post-login redirect to work without the port number being added to the URL?

Thanks,
Kristin.

Indigo

Hi Kristin, and welcome to the forums!

Thanks for reporting this — and apologies for the headache! You've uncovered a genuine bug in Indigo's reverse proxy configuration.

What's happening: The built-in nginx reverse proxy isn't passing X-Forwarded-Proto and X-Forwarded-Port headers to the backend. Without these, WordPress sees the internal backend port (eg something like :50034) instead of the standard HTTPS port 443, and dutifully includes it in redirect URLs.

The fix: We've updated the reverse proxy template to include these headers, so this will be resolved in the next Indigo release.

Workaround for now: If you'd like to fix this immediately without waiting for the update, add the following to your wp-config.php (near the top, before require_once ABSPATH . 'wp-settings.php'):

  // Workaround for reverse proxy not passing forwarded headers
  if (isset($_SERVER['HTTP_X_FORWARDED_HOST'])) {
      $_SERVER['HTTPS'] = 'on';
      $_SERVER['SERVER_PORT'] = 443;
  }

This tells WordPress to assume HTTPS on port 443 whenever it detects it's behind the reverse proxy. You can remove it after updating to the next release.

Thanks again for the report!

theboyk

Hey there—I've added that code to wp-config but still getting the port number added once I've logged in. Maybe the issue I'm seeing is introduced earlier into the process (as I can see the port in the redirect parameters, before I acutally log in. I think this has something to do with a trailing slash being added via a redirect when first accessing the wp login page. For example, typically, I would log into a site be going to:

https://local-dev-site.mydomain.com/wp-admin

This then redirects to:

https://local-dev-site.mydomain.com/wp-login.php?redirect_to=https%3A%2F%2Flocal-dev-site.mydomain.com%3A50023%2Fwp-admin%2F&reauth=1

You can see the port (50023) in in the redirect parameter. When using MAMP Pro, this is what the same URL would look like:

https://local-dev-site.mydomain.com/wp-login.php?redirect_to=https%3A%2F%2Flocal-dev-site.mydomain.com%2Fwp-admin%2F&reauth=1

The only difference is the port being/not being included in the redirect parameter.

Then, once I proceed to login (via the Indigo instance)and get into the WordPress dashboard, the URL is:

https://local-dev-site.mydomain.com:50023/wp-admin/

The reason I think it has something to do with the redirect that takes place when there's no trailing slash is that if I add that slash to the initial URL, like this:

https://local-dev-site.mydomain.com/wp-admin/

Instead of:

https://local-dev-site.mydomain.com/wp-admin

There's no issue (no port added) when manually incuding the trailing slash after wp-admin. It only happens when that trailing slash is omitted.

Thoughts?

Indigo

Thanks for the debugging! Seems I was hasty declaring this a bug in Indigo's reverse proxy config. We've now done extensive testing and unfortunately can't reproduce this situation at all on our end. Here's what we found:

Our fresh WP 6.9 install test shows everything working correctly:

Host header: local-dev-site.mydomain.com (no port)
SERVER_PORT: 443 (correct)
Trailing slash redirect: https://local-dev-site.mydomain.com/wp-admin/ (no port)
WordPress redirect_to: https://local-dev-site.mydomain.com/wp-admin/ (no port)

The bug would occur if the Host header somehow includes the internal port (e.g., Host: local-dev-site.mydomain.com:50023), which would cause PHP to see SERVER_PORT => 50023 and WordPress would then include it in generated URLs.

Could you help us debug by:

Creating a file debug-headers.php in your site root with:

<?php
header('Content-Type: text/plain');
foreach (getallheaders() as $name => $value) {
    echo "$name: $value\n";
}
echo "\nSERVER_PORT: " . ($_SERVER['SERVER_PORT'] ?? 'not set');

Visit https://local-dev-site.mydomain.com/debug-headers.php and share what you see - particularly the Host header and SERVER_PORT value.
Is there anything unusual in how you are accessing this eg is it from the same machine Indigo runs on, or from another device on your network?
Any chance there's another proxy in front (router, VPN, Cloudflare, etc.)? No tunnels etc?

When you get a chance, could you try a completely fresh WordPress install with an empty database — just to rule out any migrated config? If the problem persists with a clean install, please send me your .indigostack file and we'll try to reproduce it on our end.

What's coming in the next release: We've added X-Forwarded-Proto and X-Forwarded-Port headers to the nginx reverse proxy, which should help in edge cases. But since clean Indigo works without it, there might be something specific to your configuration we need to understand.

theboyk

OK, installed a fresh WordPress instance. Same results. Just to confirm, you're testing the, ensuring that you are NOT adding the trailing slash to https://local-dev-site.mydomain.com/wp-admin (<-- NO TRAILING SLASH)?

If I add the trailing slash everything is fine. If I just go to https://local-dev-site.mydomain.com/wp-admin (<-- NO TRAILING SLASH), that's when I get the port number in the URL. I've added that code you requested for further debugging. I added it to debug-headers.php and these are the results:

Cookie: wordpress_test_cookie=WP%20Cookie%20check; MicrosoftApplicationsTelemetryDeviceId=5859edc0-425d-4063-94b8-6bf065a6d23f; MicrosoftApplicationsTelemetryFirstLaunchTime=2025-12-17T14:13:05.938Z; wp_lang=en_US
Accept-Language: en-CA,en;q=0.9
Accept-Encoding: gzip, deflate, br, zstd
Sec-Fetch-Dest: document
Sec-Fetch-User: ?1
Sec-Fetch-Mode: navigate
Sec-Fetch-Site: none
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,image/avif,image/webp,image/apng,/;q=0.8,application/signed-exchange;v=b3;q=0.7
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_15_7) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/143.0.0.0 Safari/537.36
Upgrade-Insecure-Requests: 1
Cache-Control: no-cache
Pragma: no-cache
Connection: close
X-Forwarded-Host: local-dev-site.mydomain.com
X-Forwarded-For: ::1
X-Real-Ip: ::1
Host: local-dev-site.mydomain.com
Content-Length:
Content-Type:

SERVER_PORT: 50015

This all looks normal. And based on my original troubleshooting, I wouldn't expect the port to be involved here. The ONLY time I end up with the port in the URL is when I go to https://local-dev-site.mydomain.com/wp-admin (<-- NO TRAILING SLASH). To get some additional debug info for you, I've added a modified version of thaat code to my functions.php and am outputting the results to console (so you can see the same information as I progress through the steps to eventually end up with the port in the URL. So, here are those results:

URL: https://local-dev-site.mydomain.com/
RESULTS:

SERVER_PORT: 50015

Next, I go to...
https://local-dev-site.mydomain.com/wp-admin (<-- NO TRAILING SLASH)

...which immediately redirects to...
https://local-dev-site.mydomain.com/wp-login.php?redirect_to=https%3A%2F%2Flocal-dev-site.mydomain.com%3A50015%2Fwp-admin%2F&reauth=1

It's this redirect—from wp-admin (<-- NO TRAILING SLASH) to wp-login.php where the port (50015) is first introduced. You can see it in the redirect parameter; it's not yet in the main URL, just the redirect parameter. And these are the resuts after that redirect:

Cookie: wordpress_test_cookie=WP%20Cookie%20check; MicrosoftApplicationsTelemetryDeviceId=5859edc0-425d-4063-94b8-6bf065a6d23f; MicrosoftApplicationsTelemetryFirstLaunchTime=2025-12-17T14:13:05.938Z; wp_lang=en_US
Accept-Language: en-CA,en;q=0.9
Accept-Encoding: gzip, deflate, br, zstd
Sec-Ch-Ua-Platform: "macOS"
Sec-Ch-Ua-Mobile: ?0
Sec-Ch-Ua: "Google Chrome";v="143", "Chromium";v="143", "Not A(Brand";v="24"
Sec-Fetch-Dest: document
Sec-Fetch-User: ?1
Sec-Fetch-Mode: navigate
Sec-Fetch-Site: none
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,image/avif,image/webp,image/apng,/;q=0.8,application/signed-exchange;v=b3;q=0.7
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_15_7) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/143.0.0.0 Safari/537.36
Upgrade-Insecure-Requests: 1
Cache-Control: no-cache
Pragma: no-cache
Connection: close
X-Forwarded-Host: local-dev-site.mydomain.com
X-Forwarded-For: ::1
X-Real-Ip: ::1
Host: local-dev-site.mydomain.com
Content-Length:
Content-Type:

SERVER_PORT: 50015

Again, this is normal. No port in the actual URL yet. But it is in the redirect parameter from where these results were captured.

Finally, as I'm now on the login screen, when I log in, I end up on this URL:

https://local-dev-site.mydomain.com:50015/wp-admin/

The port number is now in the URL. And these are the results:

Cookie: MicrosoftApplicationsTelemetryDeviceId=98ee73f9-ce34-49b7-af98-af1b18271dfc; MicrosoftApplicationsTelemetryFirstLaunchTime=2025-12-17T14:08:54.170Z; wordpress_sec_3d96e7a4a99c84acef7d9913bd44b58c=kmaling%7C1766154541%7C7GVRUQmbWfz4Tv4epjEUGIDT5Dcg1k0yXuQcQEHRTMV%7Cfa3adede33566181cd0f20b347c9256e4c778f04c6e808eb5d7fdfa3f25933c3; wordpress_test_cookie=WP%20Cookie%20check; MicrosoftApplicationsTelemetryDeviceId=5859edc0-425d-4063-94b8-6bf065a6d23f; MicrosoftApplicationsTelemetryFirstLaunchTime=2025-12-17T14:13:05.938Z; wp_lang=en_US; wordpress_logged_in_3d96e7a4a99c84acef7d9913bd44b58c=kmaling%7C1766154541%7C7GVRUQmbWfz4Tv4epjEUGIDT5Dcg1k0yXuQcQEHRTMV%7C2f6fa1abc5dbd7c5d549c72beb67f3a30cf701089cef662c11fa231a26833c4f
Accept-Language: en-CA,en;q=0.9
Accept-Encoding: gzip, deflate, br, zstd
Referer: https://local-dev-site.mydomain.com/
Sec-Ch-Ua-Platform: "macOS"
Sec-Ch-Ua-Mobile: ?0
Sec-Ch-Ua: "Google Chrome";v="143", "Chromium";v="143", "Not A(Brand";v="24"
Sec-Fetch-Dest: document
Sec-Fetch-User: ?1
Sec-Fetch-Mode: navigate
Sec-Fetch-Site: same-site
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,image/avif,image/webp,image/apng,/;q=0.8,application/signed-exchange;v=b3;q=0.7
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_15_7) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/143.0.0.0 Safari/537.36
Upgrade-Insecure-Requests: 1
Cache-Control: no-cache
Pragma: no-cache
Connection: keep-alive
Host: local-dev-site.mydomain.com:50015
Content-Length:
Content-Type:

SERVER_PORT: 50015

The port nuber is now appearing in the results (host).

Finally, if I start over (log out, new window, etc.), and go here, manually adding the trailing slash this time...

https://local-dev-site.mydomain.com/wp-admin/ (<-- TRAILING SLASH MANUALLY ADDED)

...it immediately redirects to...

https://local-dev-site.mydomain.com/wp-login.php?redirect_to=https%3A%2F%2Flocal-dev-site.mydomain.com%2Fwp-admin%2F&reauth=1

And, unlike the previous attemp, when there is NO trailing slash, this time, because the trailing slash WAS added, the port doesn't end up in the redirect parameter.

So, this looks like there's something going on with the redirect of wp-admin specificialy, and only when there is no trailing slash included. This does not happen when trailing slashes are omited on other paths, like...

https://local-dev-site.mydomain.com/wp-login

That redirects properly to...

https://local-dev-site.mydomain.com/wp-login/

This only happens on https://local-dev-site.mydomain.com/wp-admin (<-- NO TRAILING SLASH)

Hoping this might narrow things down a little?

Indigo

Hey, thanks for your persistence getting to the bottom of this, really appreciate it! It's all a bit maddening!

So to clarify, I just visited https://local-dev-site.mydomain.com/wp-admin (no trailing slash) and the browser redirected to:

https://local-dev-site.mydomain.com/wp-login.php?redirect_to=https%3A%2F%2Flocal-dev-site.mydomain.com%2Fwp-admin%2F&reauth=1

When logged in, the same URL redirects me to https://local-dev-site.mydomain.com/wp-admin/ with the trailing slash. No ports.

The core mystery: We both have a clean Host header (no port), but your PHP sees SERVER_PORT: 50015 while ours sees SERVER_PORT: 443. This is what determines how WordPress constructs URLs - and explains why you get the port in the redirect but we don't.

Even when we hit Apache directly (bypassing the reverse proxy entirely) with a clean Host header, we still get SERVER_PORT: 443. So something is fundamentally different in our setups.

Could you share:

Your Indigo version (Help → About Indigo)
Your macOS version (Apple menu → About This Mac)
Your .indigostack file for the clean Wordpress test - this would let us try your exact configuration

If you'd prefer not to share the stack file publicly, feel free to email it to hello@indigostack.app and we'll investigate directly.

Starting to clutch at straws, but if you have access to another Mac or a VM I'd be very interested in the outcome there.

The X-Forwarded-Proto and X-Forwarded-Port headers we're adding in the next release might help here, since WordPress can use those instead of SERVER_PORT — but we'd really like to understand why our setups behave differently.

theboyk

Just tested it on another machine. Copied my stack, DB and WordPress install over, fresh copy of IndigoStack, and still seeing the same issue. Port first appears in the redirect parameter, then, once I log in, it's in the URL itself.

Here are the details from the two machines, as requested:

== Primary machine ==

Indigo 1.2.2 (125)
macOS 26.2 (just upgrade to Tahoe yesterday; prior to that I was running macOS 15.6.1)
MacBook Pro (M1 Pro)

== Secondary machine ==

Indigo 1.2.2 (125)
macOS 15.5
MacBook Pro (M1 Pro)

The secondary machine was a clean-install of 15.5, so nothing custom going on on that device. I also tested with the machines offline, to rule out anything network related (as we are behind Cloudflare, running Cloudflare tunnels, have split horizon DNS, and also running two proxies on the network; SWAG docker containers). I also watched network activity during the various troubleshoot steps (with network online/offline) and nothing is passing trough any of the above that might be getting in the way; traffic remains local to the device, aside from attempts to external 3rd party services WordPress tries to connect to; but nothing related to the host). And the issue persists, even when the device is completely offline.

Another thing I tried was installing a fresh copy of MAMP Pro 7 (which was what I was trying to avoid, and instead use IndigoStack). Running the same site (files + db) under MAMP, the port issue doesn't happen (running the same setup in MAMP as I had in Indigo; NGINX 1.29.3 + PHP 8.2.29 + MySQL 8 [slight .# variation in the version of MySQL running; but I can't imagine this would be the issue).

Here's a copy of all of the files I'm using—the .indigostack, db file and stock WordPress install directory. These are the same files I used for testing on both machines, as well as testing Indigo vs MAMP.

https://files.gsbranding.com/_FY1scnpswcIYdR

Let me know if I can supply anything else?

Thanks,
Kristin.

Indigo

Hey Kristin, brilliant work, thanks especially for providing your stack config. We've replicated the problem exactly now! The fundamental reason we couldn't earlier was that we were using Apache not Nginx for the Wordpress site. It's a little late here so I'll continue tomorrow but just wanted to let you know we've replicated the issue and should be able to provide a fix shortly.

theboyk

Ha! The missing piece of the puzzle. Totally my fault—I should have spec'd out my setup with the original post; appologies for that!

Indigo

Hey, sorry for the delay! Thanks again for such detailed debugging, really appreciated.

The Problem: when using Nginx as the backend server (not Apache), the internal back end port (e.g., 50015) was leaking into redirect URLs instead of the external port (443). Also, PHP was seeing the internal backend port (e.g., 50015) instead of the external port (443).

The main culprit was Nginx's automatic directory redirects - when you request /wp-admin (no trailing slash), nginx redirects to /wp-admin/ and was including the internal port in that redirect URL. We also fixed PHP's SERVER_PORT variable to ensure any PHP-generated redirects use the correct port too.

The root cause was two-fold:

The backend Nginx was using absolute URLs in its automatic redirects, which included the internal port
The reverse proxy also wasn't forwarding X-Forwarded-Port header, and the backend wasn't using it to set PHP's SERVER_PORT

This port-forwarding issue is a side effect of Indigo's more flexible multi-stack architecture. MAMP Pro doesn't have this problem because it doesn't have this flexibility — it's one server, one port config.

The Fix: the fix will be included in the next Indigo release and involves:

Backend Nginx now uses relative redirects (absolute_redirect off) so directory redirects (like /wp-admin → /wp-admin/) don't expose internal ports
Reverse proxy now sends X-Forwarded-Port and X-Forwarded-Proto headers to the backend
Backend Nginx reads X-Forwarded-Port and passes it to PHP as SERVER_PORT for any PHP-generated redirects

Sounds more complicated than it really is... just a few nginx config directives, really.

To get this going before before the next release, you can use Indigo's config override mechanism. I've attached an updated version of your DEBUG stack containing the required overrides, and can confirm this fixes the issue in my tests.

debugindigostack.zip

8kB

To replicate the fix in other stacks, create these files inside your mystack.indigostack bundle folder:

For the reverse proxy - create system/nginx_reverse_proxy/conf/sites-enabled/rp.YOUR-DOMAIN.conf and add these headers to the location block:

proxy_set_header  X-Forwarded-Proto $scheme;
proxy_set_header  X-Forwarded-Port $server_port;

For the backend Nginx - create nginx_XXXX/conf/sites-enabled/YOUR-DOMAIN.conf (where XXXX is your nginx service ID) and add:

absolute_redirect off;

And in the PHP location block:

set $real_server_port $server_port;
if ($http_x_forwarded_port) {
    set $real_server_port $http_x_forwarded_port;
}
fastcgi_param SERVER_PORT $real_server_port;

Thanks again for helping us track this down!

theboyk

Thanks for digging into this. Unfortunately, my trial ended before I had a chance to test this, and needed to jump into a couple dev jobs as soon as I returned to work from the holidays, so unfortunaately, had to renew my MAMP Pro subscription for another year. But will definitely revisit Indigo again next year prior the the renewal.
Thanks again,
Kristin.

Indigo

Hi Kristin, thanks for the update and most of all for your effort & persistence helping us improve Indigo!