DEV Community: Alessandro Mainardi

How to Fix WordPress "Too Many Redirects" in Docker behind Reverse Proxy

Alessandro Mainardi — Wed, 28 Oct 2026 08:49:05 +0000

📖 Original Reference: Originally published with full architecture diagrams and server configuration templates at alexmaina.dev/wordpress-docker-redirect-loop.

Running WordPress inside Docker behind a reverse proxy (like Nginx Proxy Manager, Traefik, Caddy, or Cloudflare) often leads to the dreaded browser error:

ERR_TOO_MANY_REDIRECTS

The browser gets trapped in an infinite HTTP 301 loop. Here is why this happens and how to permanently fix it in under 60 seconds.

⚡ The 30-Second Solution

Open your WordPress volume mount and edit wp-config.php. Paste this snippet BEFORE the line /* That's all, stop editing! Happy publishing. */:

// Trust HTTPS termination from your Reverse Proxy
if (isset($_SERVER['HTTP_X_FORWARDED_PROTO']) && strpos($_SERVER['HTTP_X_FORWARDED_PROTO'], 'https') !== false) {
    $_SERVER['HTTPS'] = 'on';
}

define('WP_HOME', 'https://yourdomain.com');
define('WP_SITEURL', 'https://yourdomain.com');
define('FORCE_SSL_ADMIN', true);

1. Anatomy of the Loop: Why Does it Happen?

In a modern containerized stack:

The user requests https://yourdomain.com (encrypted on port 443).
The Reverse Proxy terminates the SSL session (decrypts the traffic) and forwards the request internally to the WordPress container via HTTP on port 80.
Inside the container, PHP checks $_SERVER['HTTPS']. Because internal Docker network communication is unencrypted, $_SERVER['HTTPS'] is empty or off.
WordPress sees that its configured site URL is HTTPS, thinks the visitor accessed via insecure HTTP, and responds with an HTTP 301 Moved Permanently directing back to https://yourdomain.com.
The browser follows the redirect, the proxy intercepts it again on port 443, forwards it via port 80, and the cycle repeats infinitely until the browser throws ERR_TOO_MANY_REDIRECTS.

2. Nginx Reverse Proxy Headers

Ensure your upstream Nginx proxy passes the correct forwarded protocol headers:

server {
    listen 443 ssl http2;
    server_name yourdomain.com;

    location / {
        proxy_pass http://wordpress_container:80;
        proxy_set_header Host $host;
        proxy_set_header X-Real-IP $remote_addr;
        proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
        proxy_set_header X-Forwarded-Proto $scheme;
    }
}

If using Nginx Proxy Manager (NPM):

Under Details: Scheme is http, Forward Host is the container name, Port is 80.
Under SSL: Enable Force SSL and HTTP/2 Support.

3. The Cloudflare Trap: Flexible vs Full (Strict)

If your DNS is proxied through Cloudflare (orange cloud active):

Never use Flexible SSL: Flexible instructs Cloudflare to contact your origin server strictly on port 80 (HTTP). If WordPress enforces HTTPS, Cloudflare and your origin will bounce redirects back and forth indefinitely.
Fix: Change your Cloudflare SSL/TLS encryption mode to Full or Full (Strict).

4. Verification with cURL

Run this terminal command to test the raw HTTP status without browser cache pollution:

curl -ILs -o /dev/null -w "%{http_code} -> %{url_effective}\n" https://yourdomain.com

Expected output:

200 -> https://yourdomain.com/

If you see 20 consecutive 301 -> ... lines, the PHP block was either placed too late in wp-config.php or the reverse proxy is stripping the X-Forwarded-Proto header.

Author: Alessandro Mainardi — Software Developer & Computer Engineering Student @ UniBo. Explore more self-hosting & Docker guides at alexmaina.dev.

Access Your Homelab Remotely without Port Forwarding (Bypass CGNAT with Tailscale)

Alessandro Mainardi — Wed, 28 Oct 2026 08:48:18 +0000

📖 Original Reference: Originally published with zero-trust network topologies at alexmaina.dev/tailscale-pihole-homelab-cgnat.

With modern fiber (FTTH), cellular 5G, or Starlink connections, most ISPs place customer routers behind CGNAT (Carrier-Grade NAT). Under CGNAT, you do not have a public IPv4 address, rendering classic port forwarding completely useless.

Even if you have a public IP, opening ports (like port 22 or WireGuard port 51820) exposes your home router to 24/7 automated port scanners and brute-force attacks.

Here is how to set up a Tailscale Subnet Router with Pi-hole MagicDNS to gain zero-trust, encrypted remote access to every device on your home network without opening a single port.

1. Why a Subnet Router?

Instead of installing the Tailscale client on every single device (which is impossible for IoT gear, network printers, IP cameras, or legacy hardware), a Subnet Router acts as a secure gateway:

One always-on Linux host (Raspberry Pi, mini PC, or VM) acts as the bridge.
When you enable Tailscale on your laptop or phone while travelling, you can access 192.168.1.x IPs exactly as if you were on your home Wi-Fi.

2. Configure the Linux Gateway

SSH into your Linux machine and execute:

# 1. Install Tailscale
curl -fsSL https://tailscale.com/install.sh | sh

# 2. Enable IP packet forwarding in Linux kernel
echo 'net.ipv4.ip_forward = 1' | sudo tee -a /etc/sysctl.d/99-tailscale.conf
echo 'net.ipv6.conf.all.forwarding = 1' | sudo tee -a /etc/sysctl.d/99-tailscale.conf
sudo sysctl -p /etc/sysctl.d/99-tailscale.conf

# 3. Advertise your local subnet (adjust 192.168.1.0/24 to your LAN subnet)
sudo tailscale up --advertise-routes=192.168.1.0/24 --accept-dns=false

3. Approve Subnet Routes in Tailscale Console

Open the Tailscale Admin Machines Console.
Locate your gateway device and look for the Subnets badge.
Click the three dots (...) → Edit route settings...
Check the box for your subnet (e.g. 192.168.1.0/24) and click Save.

4. Integrate Pi-hole for Global Ad-Blocking & Local DNS

If you have Pi-hole or AdGuard Home running in your homelab:

In the Tailscale Admin Console, go to DNS.
Under Nameservers, click Add nameserver → Custom...
Enter your Pi-hole's local IP (e.g. 192.168.1.50) or Tailscale IP (100.x.y.z).
Toggle Override local DNS ON.

The Result:

Seamless encrypted access to Proxmox, NAS storage, and local servers from anywhere.
Network-wide ad-blocking and tracker filtering active on your phone and laptop wherever you travel.
Zero ports forwarded on your home router.

Author: Alessandro Mainardi — Software Developer & Computer Engineering Student @ UniBo. Explore homelab setups at alexmaina.dev.

QNAP Container Station: Free Up Ports 80 & 443 for Docker Reverse Proxy

Alessandro Mainardi — Wed, 28 Oct 2026 08:47:26 +0000

📖 Original Reference: Originally published with complete step-by-step storage configurations at alexmaina.dev/qnap-docker-reverse-proxy.

When trying to deploy a Reverse Proxy (like Nginx Proxy Manager, Traefik, or Caddy) inside QNAP's Container Station, Docker will fail with:

Error response from daemon: driver failed programming external connectivity on endpoint: bind: address already in use

This happens because QNAP's operating system (QTS or QuTS hero) occupies port 80 and port 443 by default for its administrative interface and built-in web server.

Here is how to liberate both ports cleanly and set up a centralized reverse proxy without breaking access to your NAS.

Step 1: Move QTS Admin System Ports

Log into your QTS web dashboard.
Go to Control Panel → System → General Settings.
Under the System Administration section:
- System port (HTTP): Change from 8080 (or 80) to 8088.
- Enable secure connection (HTTPS): Change from 443 (or 4433) to 8443.
- Uncheck: "Redirect HTTP connection to HTTPS" if bound to port 80.
Click Apply. Your browser will reload at https://NAS-IP:8443.

Step 2: Disable the Built-in Apache Web Server

Even with admin ports moved, QTS runs a background Apache server that listens on port 80.

In Control Panel, navigate to Applications → Web Server.
Uncheck Enable Web Server (or change its listening ports to 8085 and 8445).
Click Apply.

Ports 80 and 443 are now completely free on the physical network interface!

Step 3: Deploy Nginx Proxy Manager with Docker Compose

Open Container Station → Applications → Create, and paste this clean docker-compose.yml:

version: '3.8'

services:
  npm-app:
    image: 'jc21/nginx-proxy-manager:latest'
    container_name: nginx-proxy-manager
    restart: unless-stopped
    ports:
      - '80:80'    # Public HTTP port now available
      - '443:443'  # Public HTTPS port now available
      - '81:81'    # NPM Web Admin Dashboard
    environment:
      DB_MYSQL_HOST: "npm-db"
      DB_MYSQL_PORT: 3306
      DB_MYSQL_USER: "npm"
      DB_MYSQL_PASSWORD: "SuperSecureDBPassword2026!"
      DB_MYSQL_NAME: "npm"
    volumes:
      - /share/Container/npm/data:/data
      - /share/Container/npm/letsencrypt:/etc/letsencrypt
    depends_on:
      - npm-db
    networks:
      - homelab-net

  npm-db:
    image: 'mariadb:10.11'
    container_name: npm-database
    restart: unless-stopped
    environment:
      MYSQL_ROOT_PASSWORD: "RootSecretPassword2026!"
      MYSQL_DATABASE: "npm"
      MYSQL_USER: "npm"
      MYSQL_PASSWORD: "SuperSecureDBPassword2026!"
    volumes:
      - /share/Container/npm/mysql:/var/lib/mysql
    networks:
      - homelab-net

networks:
  homelab-net:
    name: homelab-net
    driver: bridge

Step 4: Route Container Traffic Internally

With all your containers attached to homelab-net:

You no longer need to expose ports to the host for individual services (WordPress, Nextcloud, etc.).
Access NPM dashboard at http://NAS-IP:81 (Default credentials: admin@example.com / changeme).
Add a Proxy Host with your domain name and set Forward Hostname to the internal container name (e.g. wordpress-app) on port 80.
Request a free Let's Encrypt SSL certificate directly through NPM.

Author: Alessandro Mainardi — Software Developer & Computer Engineering Student @ UniBo. Explore homelab architectures at alexmaina.dev.

Speed Up Python CI/CD 10x with uv: Migration from Pip & Poetry

Alessandro Mainardi — Wed, 28 Oct 2026 08:46:44 +0000

📖 Original Reference: Originally published with performance benchmarks and deployment pipelines at alexmaina.dev/python-uv-github-actions.

In standard Python CI/CD pipelines, pip install or poetry install is notoriously slow, burning 2 to 5 billable minutes on every commit just resolving wheel dependencies.

uv, created in Rust by Astral (the authors of Ruff), is an extremely fast Python package and project manager designed as a drop-in replacement for Pip, Pip-tools, Virtualenv, and Poetry.

Here is how to migrate an existing project, lock dependencies with uv.lock, and reduce your GitHub Actions workflow times from minutes to seconds.

1. Quick Migration Commands

# Install uv (Linux/macOS)
curl -LsSf https://astral.sh/uv/install.sh | sh

# Install uv (Windows PowerShell)
powershell -ExecutionPolicy ByPass -c "irm https://astral.sh/uv/install.ps1 | iex"

# Initialize standard PEP 621 project
uv init my-project
cd my-project

# Add dependencies with automatic lockfile update
uv add fastapi uvicorn "pydantic>=2.0"
uv add --dev pytest ruff

# Run tests instantly in isolated environment
uv run pytest

2. Optimized GitHub Actions Workflow

In .github/workflows/ci.yml, leverage the official astral-sh/setup-uv action with built-in cache keying:

name: Test & Lint Python

on:
  push:
    branches: [main]
  pull_request:

jobs:
  test:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4

      - name: Setup uv with automatic dependency caching
        uses: astral-sh/setup-uv@v5
        with:
          version: "latest"
          enable-cache: true
          cache-dependency-glob: "uv.lock"

      - name: Install required Python version
        run: uv python install 3.12

      - name: Sync dependencies from lockfile
        run: uv sync --frozen --all-extras --dev

      - name: Lint with Ruff
        run: uv run ruff check .

      - name: Run Pytest
        run: uv run pytest --maxfail=1 -q

3. Production Multi-Stage Dockerfile

Use uv during the build stage to compile wheels and copy strictly the finalized .venv into the production runtime container:

# STAGE 1: Dependency resolution & build
FROM ghcr.io/astral-sh/uv:python3.12-bookworm-slim AS builder

WORKDIR /app
ENV UV_COMPILE_BYTECODE=1 \
    UV_LINK_MODE=copy

COPY pyproject.toml uv.lock ./
RUN uv sync --frozen --no-dev --no-install-project

COPY . .
RUN uv sync --frozen --no-dev

# STAGE 2: Minimal runtime image
FROM python:3.12-slim-bookworm

WORKDIR /app
COPY --from=builder /app/.venv /app/.venv
COPY . /app

ENV PATH="/app/.venv/bin:$PATH"

EXPOSE 8000
CMD ["uvicorn", "main:app", "--host", "0.0.0.0", "--port", "8000"]

Author: Alessandro Mainardi — Software Developer & Computer Engineering Student @ UniBo. Explore modern tooling and software engineering guides at alexmaina.dev.

Keep Your Microsoft 365 E5 Developer Tenant Active Automatically

Alessandro Mainardi — Wed, 28 Oct 2026 08:45:43 +0000

📖 Original Reference: Originally published with security architecture baselines at alexmaina.dev/m365-developer-rinnovo-automatico.

The Microsoft 365 Developer Program provides a free 25-user E5 enterprise sandbox subscription (worth over $1,300/year). However, it comes with a strict condition: it expires every 90 days unless Microsoft detects continuous developer activity.

If your sandbox goes idle, Microsoft terminates the tenant, permanently erasing your users, mailboxes, and configurations.

Here is an automated, serverless solution using Microsoft Graph API and GitHub Actions to generate valid developer telemetry and maintain your tenant indefinitely.

1. Register a Daemon App in Microsoft Entra ID

Sign into the Microsoft Entra Admin Center as tenant admin.
Go to Identity → Applications → App registrations → New registration.
Name it M365-KeepAlive-Automation (Accounts in this organizational directory only).
Save the Application (client) ID and Directory (tenant) ID.
Under Certificates & secrets, create a new client secret (24-month validity) and copy its value.
Under API permissions → Add permission → Microsoft Graph → Application permissions, select:
- User.Read.All
- Calendars.ReadWrite
- Directory.Read.All
Click Grant admin consent for [Your Tenant].

2. Python Telemetry Script (keepalive.py)

Create keepalive.py in a private GitHub repository:

import os
import requests
from datetime import datetime, timedelta

TENANT_ID = os.environ["M365_TENANT_ID"]
CLIENT_ID = os.environ["M365_CLIENT_ID"]
CLIENT_SECRET = os.environ["M365_CLIENT_SECRET"]

# 1. Acquire OAuth2 Token via Client Credentials Flow
token_url = f"https://login.microsoftonline.com/{TENANT_ID}/oauth2/v2.0/token"
token_data = {
    "grant_type": "client_credentials",
    "client_id": CLIENT_ID,
    "client_secret": CLIENT_SECRET,
    "scope": "https://graph.microsoft.com/.default"
}

res = requests.post(token_url, data=token_data)
res.raise_for_status()
access_token = res.json()["access_token"]
headers = {"Authorization": f"Bearer {access_token}", "Content-Type": "application/json"}

print("✅ Microsoft Graph token successfully acquired.")

# 2. Query tenant user directory
users_res = requests.get("https://graph.microsoft.com/v1.0/users?$top=5", headers=headers)
users = users_res.json().get("value", [])
print(f"📡 Found {len(users)} users in tenant.")

# 3. Create simulated developer calendar event
if users:
    target_user_id = users[0]["id"]
    now = datetime.utcnow()
    event_payload = {
        "subject": f"Dev Sprint Sync - {now.strftime('%Y-%m-%d %H:%M')}",
        "body": {"contentType": "HTML", "content": "Automated Graph API Developer Telemetry."},
        "start": {"dateTime": (now + timedelta(hours=1)).isoformat(), "timeZone": "UTC"},
        "end": {"dateTime": (now + timedelta(hours=2)).isoformat(), "timeZone": "UTC"}
    }

    event_res = requests.post(
        f"https://graph.microsoft.com/v1.0/users/{target_user_id}/events",
        headers=headers,
        json=event_payload
    )
    if event_res.status_code == 201:
        print("📅 Developer telemetry event created in calendar.")

3. GitHub Actions Cron Workflow

In .github/workflows/keepalive.yml:

name: M365 E5 KeepAlive Automation

on:
  schedule:
    # Runs Monday, Wednesday, Friday at 08:30 UTC
    - cron: '30 8 * * 1,3,5'
  workflow_dispatch:

jobs:
  telemetry:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4

      - uses: actions/setup-python@v5
        with:
          python-version: '3.12'

      - run: pip install requests

      - name: Run Graph Telemetry
        env:
          M365_TENANT_ID: ${{ secrets.M365_TENANT_ID }}
          M365_CLIENT_ID: ${{ secrets.M365_CLIENT_ID }}
          M365_CLIENT_SECRET: ${{ secrets.M365_CLIENT_SECRET }}
        run: python keepalive.py

Store M365_TENANT_ID, M365_CLIENT_ID, and M365_CLIENT_SECRET under Repository Settings → Secrets and variables → Actions.

Author: Alessandro Mainardi — Software Developer & Computer Engineering Student @ UniBo. Explore cloud identity guides at alexmaina.dev.

How to Fix Error AADSTS50011 in Microsoft Entra ID (Redirect URI Mismatch)

Alessandro Mainardi — Wed, 28 Oct 2026 08:43:35 +0000

📖 Original Reference: Originally published with interactive diagrams and enterprise identity baselines at alexmaina.dev/entra-id-redirect-uri-aadsts50011.

If you are developing applications using MSAL (Microsoft Authentication Library) and Microsoft Entra ID (formerly Azure AD), you have likely run into this frustrating blocker:

AADSTS50011: The reply URL specified in the request does not match the reply URLs configured for the application '{client-id}'.

This error appears during the OAuth 2.0 / OpenID Connect authorization handshake. Microsoft's token endpoint performs a strict character-by-character validation, meaning even a single trailing slash or port mismatch will immediately halt authentication.

Here is how to diagnose the root cause and fix it in under 3 minutes.

1. The 4 Most Common Causes of Mismatch

Root Cause	What MSAL Request Sends	What Entra ID App Has Configured
Trailing Slash	`http://localhost:3000`	`http://localhost:3000/`
Protocol Scheme	`https://app.mydomain.com/callback`	`http://app.mydomain.com/callback`
Dynamic Dev Port	`http://localhost:5173` (Vite)	`http://localhost:3000` (Create-React-App)
Wrong Platform Type	SPA with PKCE (CORS)	Configured under "Web" section

2. Step-by-Step Fix via Microsoft Entra Admin Center

Navigate to the Microsoft Entra Admin Center.
Go to Identity → Applications → App registrations.
Select the All applications tab and open your registered application (match the client-id from your error log).
In the left navigation menu, click Authentication.
Inspect your platform configuration:
- Single-Page Application (SPA): If you are using React, Vue, Angular, or vanilla JS with MSAL Browser (Auth Code flow with PKCE), your URI MUST be under the Single-page application section. If registered under "Web", token requests will fail due to missing CORS headers.
- Web: Use this only for backend-rendered apps with client secrets (Next.js server-side, Node/Express, Django, Flask, ASP.NET Core).
- Mobile and desktop applications: Required for CLI tools, PowerShell, Python scripts, or desktop apps using loopback listeners (http://localhost).
Paste the exact Redirect URI from the error message.
Click Save at the top.

3. Fast Fix with Microsoft Graph PowerShell

If you frequently rotate ports during local testing, you can update redirect URIs programmatically using the official Microsoft Graph PowerShell SDK:

# Authenticate to Microsoft Graph
Connect-MgGraph -Scopes "Application.ReadWrite.All"

$AppId = "YOUR-APPLICATION-CLIENT-ID"
$App = Get-MgApplication -Filter "appId eq '$AppId'"

# Configure allowed redirect URIs for local dev + production
$SpaRedirects = @(
    "http://localhost:3000",
    "http://localhost:5173",
    "https://alexmaina.dev/auth/callback"
)

# Update SPA Platform configuration
Update-MgApplication -ApplicationId $App.Id -Spa @{ RedirectUris = $SpaRedirects }

Write-Host "✅ Redirect URIs successfully updated for: $($App.DisplayName)" -ForegroundColor Green

4. Crucial Rules for Localhost in Entra ID

HTTP is strictly reserved for Localhost: Microsoft Entra ID enforces HTTPS for all production domain redirect URIs. The only exception is loopback addresses (http://localhost or http://127.0.0.1).
Wildcards are deprecated: Microsoft no longer allows wildcard characters (*) in redirect URIs for security reasons (preventing token interception and open-redirect attacks). Each callback endpoint must be explicitly declared.

Need Deep Dive Architecture?

For full zero-trust setups, enterprise RBAC baselines, and tenant isolation, check out my technical guide hub at alexmaina.dev.

Author: Alessandro Mainardi — Software Developer & Computer Engineering Student @ Alma Mater Studiorum - University of Bologna.