pangolin & wordpress #567

New Issue

GiteaMirror · 2025-11-13T12:04:33-06:00

GiteaMirror commented

2025-11-13 12:04:33 -06:00

Originally created by @Valley8140 on GitHub (Aug 7, 2025).

I run into to difficulties trying to get a Wordpress site available using Pangolin. Always timing out.
Same result using wildcard certs or default http. Any other resource on the same server is accessible.

Originally created by @Valley8140 on GitHub (Aug 7, 2025). I run into to difficulties trying to get a Wordpress site available using Pangolin. Always timing out. Same result using wildcard certs or default http. Any other resource on the same server is accessible. <img width="909" height="563" alt="Image" src="https://github.com/user-attachments/assets/53c0bb88-2a56-4586-8591-145c5fda5976" />

GiteaMirror added the stale label 2025-11-13 12:04:33 -06:00

GiteaMirror closed this issue

2025-11-13 12:04:33 -06:00

GiteaMirror commented

2025-11-13 12:04:34 -06:00

@miloschwartz commented on GitHub (Aug 7, 2025):

Are there any errors in Newt when you try to request the resource and it times out?

@miloschwartz commented on GitHub (Aug 7, 2025): Are there any errors in Newt when you try to request the resource and it times out?

GiteaMirror commented

2025-11-13 12:04:35 -06:00

@marcschaeferger commented on GitHub (Aug 7, 2025):

Also try running a curl command directly from within the Pangolin pod to test connectivity to Wordpress or the Proxy infront of Wordpress...

@marcschaeferger commented on GitHub (Aug 7, 2025): Also try running a curl command directly from within the Pangolin pod to test connectivity to Wordpress or the Proxy infront of Wordpress...

GiteaMirror commented

2025-11-13 12:04:35 -06:00

@Valley8140 commented on GitHub (Aug 8, 2025):

Newt log only shows
Started tcp proxy to zzz.xxx.yy.qq:port#

As for curl; do you mean to use curl from within the container? If so; his was the result:
curl: (28) Failed to connect to zzz.xxx.yy.qq port # after 129164 ms: Could not connect to server

(zzz etc being the local ip)

@Valley8140 commented on GitHub (Aug 8, 2025): Newt log only shows `Started tcp proxy to zzz.xxx.yy.qq:port#` As for curl; do you mean to use curl from within the container? If so; his was the result: `curl: (28) Failed to connect to zzz.xxx.yy.qq port # after 129164 ms: Could not connect to server` (zzz etc being the local ip)

GiteaMirror commented

2025-11-13 12:04:35 -06:00

@oschwartz10612 commented on GitHub (Aug 8, 2025):

Was this curl request from inside the newt container? If so that would indicate that it cant reach the wordpress website.

But what do you mean by time out? When you visit the site does it just load and nothing happens? Usually if newt cant reach you get a bad gateway error!

How do you have Wordpress deployed and where is newt in relation to it?

@oschwartz10612 commented on GitHub (Aug 8, 2025): Was this curl request from inside the newt container? If so that would indicate that it cant reach the wordpress website. But what do you mean by time out? When you visit the site does it just load and nothing happens? Usually if newt cant reach you get a bad gateway error! How do you have Wordpress deployed and where is newt in relation to it?

GiteaMirror commented

2025-11-13 12:04:35 -06:00

@Valley8140 commented on GitHub (Aug 8, 2025):

sorry the above curl command was sent in the Pangolin container, using curl within Newt I can reach the local ip. So, both Newt and Wordpress are on the same server and using the same Docker network. For Wordpress I'm using the setup as described here . Also tried the one here, but same result.

I can reach the Pangolin password stage but after that I'm told "This site can’t be reached...
subdomain.tld.net took too long to respond"

@Valley8140 commented on GitHub (Aug 8, 2025): sorry the above curl command was sent in the Pangolin container, using curl within Newt I can reach the local ip. So, both Newt and Wordpress are on the same server and using the same Docker network. For Wordpress I'm using the setup as described [ here ](https://www.tutorials24x7.com/devops/containerize-wordpress-with-nginx-php-mysql-and-phpmyadmin-using-docker-containers). Also tried the one [here](https://github.com/hhftechnology/wordpress-docker), but same result. I can reach the Pangolin password stage but after that I'm told _"This site can’t be reached... subdomain.tld.net took too long to respond"_

GiteaMirror commented

2025-11-13 12:04:36 -06:00

@marcschaeferger commented on GitHub (Aug 9, 2025):

@Valley8140 It is likely that your Nginx configuration is causing the issues when accessing WordPress over Pangolin. Depending on your desired outcome, you may not even need Nginx because of Traefik in the Pangolin Setup.

What is Your Desired Setup?

Should the entire website, including WordPress admin access, be routed through Pangolin?
Should the public website be accessible to everyone, while the WordPress backend (/wp-admin) is restricted (authentication via Pangolin or similar mechanism) or you want the whole website incl WordPress public?

Example: Minimal Demo Setup (Not Production Ready! e.g don't use latest...)

services:
  db:
    image: mysql:latest
    container_name: db
    restart: always
    volumes:
      - db_data:/var/lib/mysql
    environment:
      MYSQL_ROOT_PASSWORD: Wordpress2025!
      MYSQL_DATABASE: wordpress
      MYSQL_USER: wordpress
      MYSQL_PASSWORD: Wordpress2025!

  wordpress:
    image: wordpress:latest
    container_name: wordpress
    restart: always
    depends_on:
      - db
      - phpmyadmin
    environment:
      WORDPRESS_DB_HOST: db:3306
      WORDPRESS_DB_USER: wordpress
      WORDPRESS_DB_PASSWORD: Wordpress2025!
      WORDPRESS_DB_NAME: wordpress
    ports:
      - "8888:80"

  phpmyadmin:
    depends_on:
      - db
    image: phpmyadmin/phpmyadmin:latest
    container_name: phpmyadmin
    restart: always
    ports:
      - "8180:80"
    environment:
      PMA_HOST: db
      MYSQL_ROOT_PASSWORD: Wordpress2025!

  newt:
    # (Your configuration here)
    ...
volumes:
  db_data:

Important notes:

Do NOT use latest tags in production — always specify image versions.

Example Screenshots

@marcschaeferger commented on GitHub (Aug 9, 2025): @Valley8140 It is likely that your Nginx configuration is causing the issues when accessing WordPress over Pangolin. Depending on your desired outcome, you may not even need Nginx because of Traefik in the Pangolin Setup. ## What is Your Desired Setup? - **Should the entire website, including WordPress admin access, be routed through Pangolin?** - **Should the public website be accessible to everyone, while the WordPress backend (`/wp-admin`) is restricted (authentication via Pangolin or similar mechanism) or you want the whole website incl WordPress public?** --- ### Example: Minimal Demo Setup (Not Production Ready! e.g don't use latest...) ```yaml services: db: image: mysql:latest container_name: db restart: always volumes: - db_data:/var/lib/mysql environment: MYSQL_ROOT_PASSWORD: Wordpress2025! MYSQL_DATABASE: wordpress MYSQL_USER: wordpress MYSQL_PASSWORD: Wordpress2025! wordpress: image: wordpress:latest container_name: wordpress restart: always depends_on: - db - phpmyadmin environment: WORDPRESS_DB_HOST: db:3306 WORDPRESS_DB_USER: wordpress WORDPRESS_DB_PASSWORD: Wordpress2025! WORDPRESS_DB_NAME: wordpress ports: - "8888:80" phpmyadmin: depends_on: - db image: phpmyadmin/phpmyadmin:latest container_name: phpmyadmin restart: always ports: - "8180:80" environment: PMA_HOST: db MYSQL_ROOT_PASSWORD: Wordpress2025! newt: # (Your configuration here) ... volumes: db_data: ``` --- **_Important notes:_** - Do **NOT** use `latest` tags in production — always specify image versions. --- #### Example Screenshots <img width="1559" height="811" alt="Demo Screenshot 1" src="https://github.com/user-attachments/assets/45956f7a-47d5-4210-804b-71448c7bd257" /> --- <img width="1268" height="943" alt="Demo Screenshot 2" src="https://github.com/user-attachments/assets/2f7512cc-b53f-4160-9e55-ea7ce523c830" />

GiteaMirror commented

2025-11-13 12:04:36 -06:00

@Valley8140 commented on GitHub (Aug 14, 2025):

This seems to working quite alright, or at least brings me a lot closer to what I want to achieve. It still does a "Bad Gateway" on me...intermittently. Reloading then gives me the full website (most of the time).
Can this occasional Bad Gateway be avoided by increasing a time out here or there...?

@Valley8140 commented on GitHub (Aug 14, 2025): This seems to working quite alright, or at least brings me a lot closer to what I want to achieve. It still does a "Bad Gateway" on me...intermittently. Reloading then gives me the full website (most of the time). Can this occasional Bad Gateway be avoided by increasing a time out here or there...?

GiteaMirror commented

2025-11-13 12:04:36 -06:00

@oschwartz10612 commented on GitHub (Aug 16, 2025):

"Bad Gateway" on me...intermittently

This smells like a newt issue. Could you post your newt logs and/or turn
on debug for newt (--log-level debug) and see if it is failing to ping
and reconnecting or something? And are you on the latest newt 1.4.1?

@oschwartz10612 commented on GitHub (Aug 16, 2025): > "Bad Gateway" on me...intermittently This smells like a newt issue. Could you post your newt logs and/or turn on debug for newt (--log-level debug) and see if it is failing to ping and reconnecting or something? And are you on the latest newt 1.4.1?

GiteaMirror commented

2025-11-13 12:04:36 -06:00

@Valley8140 commented on GitHub (Aug 16, 2025):

ERROR: 2025/08/16 08:39:18 Error connecting to target: dial tcp ipnumber:portnumber: connect: connection refused
WARN: 2025/08/16 08:39:47 Periodic ping failed (2 consecutive failures): all 2 ping attempts failed, last error: failed to read ICMP packet: i/o timeout
WARN: 2025/08/16 08:40:00 Periodic ping failed (3 consecutive failures): all 2 ping attempts failed, last error: failed to read ICMP packet: i/o timeout
WARN: 2025/08/16 08:40:16 Periodic ping failed (4 consecutive failures): all 2 ping attempts failed, last error: failed to read ICMP packet: i/o timeout
WARN: 2025/08/16 08:40:16 Connection to server lost after 4 failures. Continuous reconnection attempts will be made.

I have updated to 1.4.1 but that does not seem to make any difference

@Valley8140 commented on GitHub (Aug 16, 2025): _ERROR: 2025/08/16 08:39:18 Error connecting to target: dial tcp ipnumber:portnumber: connect: connection refused WARN: 2025/08/16 08:39:47 Periodic ping failed (2 consecutive failures): all 2 ping attempts failed, last error: failed to read ICMP packet: i/o timeout WARN: 2025/08/16 08:40:00 Periodic ping failed (3 consecutive failures): all 2 ping attempts failed, last error: failed to read ICMP packet: i/o timeout WARN: 2025/08/16 08:40:16 Periodic ping failed (4 consecutive failures): all 2 ping attempts failed, last error: failed to read ICMP packet: i/o timeout WARN: 2025/08/16 08:40:16 Connection to server lost after 4 failures. Continuous reconnection attempts will be made._ I have updated to 1.4.1 but that does not seem to make any difference

GiteaMirror commented

2025-11-13 12:04:37 -06:00

@oschwartz10612 commented on GitHub (Aug 16, 2025):

The first line:

Error connecting to target: dial tcp ipnumber:portnumber: connect:
connection refused

Seems like it failed to reach the target which is concerning

And the rest of the lines

Periodic ping failed (2 consecutive failures): all 2 ping attempts
failed, last error: failed to read ICMP packet: i/o timeout

Indicate that it is failing to ping the cloud.

Wondering if you have some transient network issues here. It seems like
at times newt can both not reach the cloud and the target. Hows your
internet connection? Is it usually stable?

One thing you could try is to increase the ping interval and ping
timeout found in the readme with the cli args or the env vars to make it
less aggressive on timing out the pings and see if that helps.

@oschwartz10612 commented on GitHub (Aug 16, 2025): The first line: > Error connecting to target: dial tcp ipnumber:portnumber: connect: connection refused Seems like it failed to reach the target which is concerning And the rest of the lines > Periodic ping failed (2 consecutive failures): all 2 ping attempts failed, last error: failed to read ICMP packet: i/o timeout Indicate that it is failing to ping the cloud. Wondering if you have some transient network issues here. It seems like at times newt can both not reach the cloud and the target. Hows your internet connection? Is it usually stable? One thing you could try is to increase the ping interval and ping timeout found in the readme with the cli args or the env vars to make it less aggressive on timing out the pings and see if that helps.

GiteaMirror commented

2025-11-13 12:04:37 -06:00

@github-actions[bot] commented on GitHub (Aug 31, 2025):

This issue has been automatically marked as stale due to 14 days of inactivity. It will be closed in 14 days if no further activity occurs.

@github-actions[bot] commented on GitHub (Aug 31, 2025): This issue has been automatically marked as stale due to 14 days of inactivity. It will be closed in 14 days if no further activity occurs.

GiteaMirror commented

2025-11-13 12:04:37 -06:00

@github-actions[bot] commented on GitHub (Sep 15, 2025):

This issue has been automatically closed due to inactivity. If you believe this is still relevant, please open a new issue with up-to-date information.

@github-actions[bot] commented on GitHub (Sep 15, 2025): This issue has been automatically closed due to inactivity. If you believe this is still relevant, please open a new issue with up-to-date information.