[GH-ISSUE #2186] The web UI shows the site as online, but actual access results in a Gateway Timeout error. #2091

Closed
opened 2026-04-16 09:04:50 -05:00 by GiteaMirror · 6 comments
Owner

Originally created by @Transwarpcom on GitHub (Dec 30, 2025).
Original GitHub issue: https://github.com/fosrl/pangolin/issues/2186

Describe the Bug

The web UI shows the site as online, but actual access results in a Gateway Timeout error. The firewall is correctly configured, Cloudflare DNS proxy is disabled, and the site was installed using the official installer.
The log is as follows
Dec 30 23:13:29 Ubuntu-LXC systemd[1]: Started newt.service - Newt.
Dec 30 23:13:29 Ubuntu-LXC newt[21626]: INFO: 2025/12/30 23:13:29 Newt version 1.8.1
Dec 30 23:13:30 Ubuntu-LXC newt[21626]: INFO: 2025/12/30 23:13:30 Server version: 1.14.1
Dec 30 23:13:30 Ubuntu-LXC newt[21626]: INFO: 2025/12/30 23:13:30 Websocket connected
Dec 30 23:13:30 Ubuntu-LXC newt[21626]: INFO: 2025/12/30 23:13:30 Connecting to endpoint: pangolin.mydomain.com
Dec 30 23:14:01 Ubuntu-LXC newt[21626]: WARN: 2025/12/30 23:14:01 Initial reliable ping failed, but continuing: all 5 ping attempts failed, last error: failed to read ICMP packet: i/o timeout
Dec 30 23:14:06 Ubuntu-LXC newt[21626]: WARN: 2025/12/30 23:14:06 Ping attempt 1 failed: failed to read ICMP packet: i/o timeout
Dec 30 23:14:06 Ubuntu-LXC newt[21626]: INFO: 2025/12/30 23:14:06 Started tcp proxy to 192.168.1.1:80
Dec 30 23:14:06 Ubuntu-LXC newt[21626]: INFO: 2025/12/30 23:14:06 Started tcp proxy to localhost:5443
Dec 30 23:14:11 Ubuntu-LXC newt[21626]: WARN: 2025/12/30 23:14:11 Ping attempt 2 failed: failed to read ICMP packet: i/o timeout
Dec 30 23:14:18 Ubuntu-LXC newt[21626]: WARN: 2025/12/30 23:14:18 Ping attempt 3 failed: failed to read ICMP packet: i/o timeout
Dec 30 23:14:25 Ubuntu-LXC newt[21626]: WARN: 2025/12/30 23:14:25 Ping attempt 4 failed: failed to read ICMP packet: i/o timeout
Dec 30 23:14:32 Ubuntu-LXC newt[21626]: WARN: 2025/12/30 23:14:32 Ping attempt 5 failed: failed to read ICMP packet: i/o timeout
Dec 30 23:14:32 Ubuntu-LXC newt[21626]: INFO: 2025/12/30 23:14:32 Increasing ping retry delay to 3s
Dec 30 23:14:40 Ubuntu-LXC newt[21626]: WARN: 2025/12/30 23:14:40 Ping attempt 6 failed: failed to read ICMP packet: i/o timeout
Dec 30 23:14:48 Ubuntu-LXC newt[21626]: WARN: 2025/12/30 23:14:48 Ping attempt 7 failed: failed to read ICMP packet: i/o timeout
Dec 30 23:14:50 Ubuntu-LXC newt[21626]: WARN: 2025/12/30 23:14:50 Periodic ping failed (2 consecutive failures): all 2 ping attempts failed, last error: failed to read ICMP packet: i/o timeout
Dec 30 23:14:56 Ubuntu-LXC newt[21626]: WARN: 2025/12/30 23:14:56 Ping attempt 8 failed: failed to read ICMP packet: i/o timeout
Dec 30 23:15:04 Ubuntu-LXC newt[21626]: WARN: 2025/12/30 23:15:04 Ping attempt 9 failed: failed to read ICMP packet: i/o timeout
Dec 30 23:15:12 Ubuntu-LXC newt[21626]: WARN: 2025/12/30 23:15:12 Ping attempt 10 failed: failed to read ICMP packet: i/o timeout
Dec 30 23:15:12 Ubuntu-LXC newt[21626]: INFO: 2025/12/30 23:15:12 Increasing ping retry delay to 4.5s
Dec 30 23:15:21 Ubuntu-LXC newt[21626]: WARN: 2025/12/30 23:15:21 Periodic ping failed (3 consecutive failures): all 2 ping attempts failed, last error: failed to read ICMP packet: i/o timeout
Dec 30 23:15:21 Ubuntu-LXC newt[21626]: WARN: 2025/12/30 23:15:21 Ping attempt 11 failed: failed to read ICMP packet: i/o timeout
Dec 30 23:15:31 Ubuntu-LXC newt[21626]: WARN: 2025/12/30 23:15:31 Ping attempt 12 failed: failed to read ICMP packet: i/o timeout
Dec 30 23:15:40 Ubuntu-LXC newt[21626]: WARN: 2025/12/30 23:15:40 Ping attempt 13 failed: failed to read ICMP packet: i/o timeout
Dec 30 23:15:50 Ubuntu-LXC newt[21626]: WARN: 2025/12/30 23:15:50 Ping attempt 14 failed: failed to read ICMP packet: i/o timeout
Dec 30 23:15:51 Ubuntu-LXC newt[21626]: WARN: 2025/12/30 23:15:51 Periodic ping failed (4 consecutive failures): all 2 ping attempts failed, last error: failed to read ICMP packet: i/o timeout
Dec 30 23:15:51 Ubuntu-LXC newt[21626]: WARN: 2025/12/30 23:15:51 Connection to server lost after 4 failures. Continuous reconnection attempts will be made.
Dec 30 23:15:52 Ubuntu-LXC newt[21626]: INFO: 2025/12/30 23:15:52 Stopping ping check
Dec 30 23:15:52 Ubuntu-LXC newt[21626]: INFO: 2025/12/30 23:15:52 Connecting to endpoint: pangolin.mydomain.com
Dec 30 23:16:22 Ubuntu-LXC newt[21626]: WARN: 2025/12/30 23:16:22 Initial reliable ping failed, but continuing: all 5 ping attempts failed, last error: failed to read ICMP packet: i/o timeout
Dec 30 23:16:27 Ubuntu-LXC newt[21626]: WARN: 2025/12/30 23:16:27 Ping attempt 1 failed: failed to read ICMP packet: i/o timeout
Dec 30 23:16:27 Ubuntu-LXC newt[21626]: INFO: 2025/12/30 23:16:27 Started tcp proxy to 192.168.1.1:80
Dec 30 23:16:27 Ubuntu-LXC newt[21626]: INFO: 2025/12/30 23:16:27 Started tcp proxy to localhost:5443

Environment

  • OS Type & Version: Ubuntu 25.10 (NEWT) Ubuntu 25.04 (Pangolin Docker server)
  • Pangolin Version: 1.14.1
  • Gerbil Version: 1.3.0
  • Traefik Version: 3.6
  • Newt Version: 1.8.1
  • Olm Version: (if applicable)

To Reproduce

I encountered this problem after a normal installation. I've tried clean installation multiple times.

Expected Behavior

Working correctly

Originally created by @Transwarpcom on GitHub (Dec 30, 2025). Original GitHub issue: https://github.com/fosrl/pangolin/issues/2186 ### Describe the Bug The web UI shows the site as online, but actual access results in a Gateway Timeout error. The firewall is correctly configured, Cloudflare DNS proxy is disabled, and the site was installed using the official installer. The log is as follows Dec 30 23:13:29 Ubuntu-LXC systemd[1]: Started newt.service - Newt. Dec 30 23:13:29 Ubuntu-LXC newt[21626]: INFO: 2025/12/30 23:13:29 Newt version 1.8.1 Dec 30 23:13:30 Ubuntu-LXC newt[21626]: INFO: 2025/12/30 23:13:30 Server version: 1.14.1 Dec 30 23:13:30 Ubuntu-LXC newt[21626]: INFO: 2025/12/30 23:13:30 Websocket connected Dec 30 23:13:30 Ubuntu-LXC newt[21626]: INFO: 2025/12/30 23:13:30 Connecting to endpoint: pangolin.mydomain.com Dec 30 23:14:01 Ubuntu-LXC newt[21626]: WARN: 2025/12/30 23:14:01 Initial reliable ping failed, but continuing: all 5 ping attempts failed, last error: failed to read ICMP packet: i/o timeout Dec 30 23:14:06 Ubuntu-LXC newt[21626]: WARN: 2025/12/30 23:14:06 Ping attempt 1 failed: failed to read ICMP packet: i/o timeout Dec 30 23:14:06 Ubuntu-LXC newt[21626]: INFO: 2025/12/30 23:14:06 Started tcp proxy to 192.168.1.1:80 Dec 30 23:14:06 Ubuntu-LXC newt[21626]: INFO: 2025/12/30 23:14:06 Started tcp proxy to localhost:5443 Dec 30 23:14:11 Ubuntu-LXC newt[21626]: WARN: 2025/12/30 23:14:11 Ping attempt 2 failed: failed to read ICMP packet: i/o timeout Dec 30 23:14:18 Ubuntu-LXC newt[21626]: WARN: 2025/12/30 23:14:18 Ping attempt 3 failed: failed to read ICMP packet: i/o timeout Dec 30 23:14:25 Ubuntu-LXC newt[21626]: WARN: 2025/12/30 23:14:25 Ping attempt 4 failed: failed to read ICMP packet: i/o timeout Dec 30 23:14:32 Ubuntu-LXC newt[21626]: WARN: 2025/12/30 23:14:32 Ping attempt 5 failed: failed to read ICMP packet: i/o timeout Dec 30 23:14:32 Ubuntu-LXC newt[21626]: INFO: 2025/12/30 23:14:32 Increasing ping retry delay to 3s Dec 30 23:14:40 Ubuntu-LXC newt[21626]: WARN: 2025/12/30 23:14:40 Ping attempt 6 failed: failed to read ICMP packet: i/o timeout Dec 30 23:14:48 Ubuntu-LXC newt[21626]: WARN: 2025/12/30 23:14:48 Ping attempt 7 failed: failed to read ICMP packet: i/o timeout Dec 30 23:14:50 Ubuntu-LXC newt[21626]: WARN: 2025/12/30 23:14:50 Periodic ping failed (2 consecutive failures): all 2 ping attempts failed, last error: failed to read ICMP packet: i/o timeout Dec 30 23:14:56 Ubuntu-LXC newt[21626]: WARN: 2025/12/30 23:14:56 Ping attempt 8 failed: failed to read ICMP packet: i/o timeout Dec 30 23:15:04 Ubuntu-LXC newt[21626]: WARN: 2025/12/30 23:15:04 Ping attempt 9 failed: failed to read ICMP packet: i/o timeout Dec 30 23:15:12 Ubuntu-LXC newt[21626]: WARN: 2025/12/30 23:15:12 Ping attempt 10 failed: failed to read ICMP packet: i/o timeout Dec 30 23:15:12 Ubuntu-LXC newt[21626]: INFO: 2025/12/30 23:15:12 Increasing ping retry delay to 4.5s Dec 30 23:15:21 Ubuntu-LXC newt[21626]: WARN: 2025/12/30 23:15:21 Periodic ping failed (3 consecutive failures): all 2 ping attempts failed, last error: failed to read ICMP packet: i/o timeout Dec 30 23:15:21 Ubuntu-LXC newt[21626]: WARN: 2025/12/30 23:15:21 Ping attempt 11 failed: failed to read ICMP packet: i/o timeout Dec 30 23:15:31 Ubuntu-LXC newt[21626]: WARN: 2025/12/30 23:15:31 Ping attempt 12 failed: failed to read ICMP packet: i/o timeout Dec 30 23:15:40 Ubuntu-LXC newt[21626]: WARN: 2025/12/30 23:15:40 Ping attempt 13 failed: failed to read ICMP packet: i/o timeout Dec 30 23:15:50 Ubuntu-LXC newt[21626]: WARN: 2025/12/30 23:15:50 Ping attempt 14 failed: failed to read ICMP packet: i/o timeout Dec 30 23:15:51 Ubuntu-LXC newt[21626]: WARN: 2025/12/30 23:15:51 Periodic ping failed (4 consecutive failures): all 2 ping attempts failed, last error: failed to read ICMP packet: i/o timeout Dec 30 23:15:51 Ubuntu-LXC newt[21626]: WARN: 2025/12/30 23:15:51 Connection to server lost after 4 failures. Continuous reconnection attempts will be made. Dec 30 23:15:52 Ubuntu-LXC newt[21626]: INFO: 2025/12/30 23:15:52 Stopping ping check Dec 30 23:15:52 Ubuntu-LXC newt[21626]: INFO: 2025/12/30 23:15:52 Connecting to endpoint: pangolin.mydomain.com Dec 30 23:16:22 Ubuntu-LXC newt[21626]: WARN: 2025/12/30 23:16:22 Initial reliable ping failed, but continuing: all 5 ping attempts failed, last error: failed to read ICMP packet: i/o timeout Dec 30 23:16:27 Ubuntu-LXC newt[21626]: WARN: 2025/12/30 23:16:27 Ping attempt 1 failed: failed to read ICMP packet: i/o timeout Dec 30 23:16:27 Ubuntu-LXC newt[21626]: INFO: 2025/12/30 23:16:27 Started tcp proxy to 192.168.1.1:80 Dec 30 23:16:27 Ubuntu-LXC newt[21626]: INFO: 2025/12/30 23:16:27 Started tcp proxy to localhost:5443 ### Environment - OS Type & Version: Ubuntu 25.10 (NEWT) Ubuntu 25.04 (Pangolin Docker server) - Pangolin Version: 1.14.1 - Gerbil Version: 1.3.0 - Traefik Version: 3.6 - Newt Version: 1.8.1 - Olm Version: (if applicable) ### To Reproduce I encountered this problem after a normal installation. I've tried clean installation multiple times. ### Expected Behavior Working correctly
Author
Owner

@Transwarpcom commented on GitHub (Dec 30, 2025):

Incidentally, my tests on non-LXC physical machines were the same.

<!-- gh-comment-id:3699689638 --> @Transwarpcom commented on GitHub (Dec 30, 2025): Incidentally, my tests on non-LXC physical machines were the same.
Author
Owner

@AstralDestiny commented on GitHub (Dec 30, 2025):

Where's newt in relation to pangolin? If newt is on the same network it'll fail as hairpin nat, You can force a connection by rewritiing it to attempt a connection to the lan ip over the wan ip.. The ICMP time out is saying the tunnel isn't even online, That happens over the tunnel and not a connection between directly outside of the tunnel.

<!-- gh-comment-id:3700179641 --> @AstralDestiny commented on GitHub (Dec 30, 2025): Where's newt in relation to pangolin? If newt is on the same network it'll fail as hairpin nat, You can force a connection by rewritiing it to attempt a connection to the lan ip over the wan ip.. The ICMP time out is saying the tunnel isn't even online, That happens over the tunnel and not a connection between directly outside of the tunnel.
Author
Owner

@Transwarpcom commented on GitHub (Dec 31, 2025):

newt 和 pangolin 的关系是什么?如果 newt 和 pangolin 在同一个网络中,由于是环回 NAT,连接会失败。你可以通过重写请求,尝试通过 WAN IP 连接到 LAN IP 来强制建立连接。ICMP 超时表明隧道根本没有连接。这种情况发生在隧道内部,而不是隧道外部的直接连接。

I'm certain that Pangolin and Newt are not on the same network.

<!-- gh-comment-id:3701687481 --> @Transwarpcom commented on GitHub (Dec 31, 2025): > newt 和 pangolin 的关系是什么?如果 newt 和 pangolin 在同一个网络中,由于是环回 NAT,连接会失败。你可以通过重写请求,尝试通过 WAN IP 连接到 LAN IP 来强制建立连接。ICMP 超时表明隧道根本没有连接。这种情况发生在隧道内部,而不是隧道外部的直接连接。 I'm certain that Pangolin and Newt are not on the same network.
Author
Owner

@Transwarpcom commented on GitHub (Dec 31, 2025):

May same to: https://github.com/fosrl/pangolin/issues/576

<!-- gh-comment-id:3701807731 --> @Transwarpcom commented on GitHub (Dec 31, 2025): May same to: https://github.com/fosrl/pangolin/issues/576
Author
Owner

@Transwarpcom commented on GitHub (Dec 31, 2025):

I have identified the root cause. This is not a bug in the software, but a network censorship issue (GFW in Mainland China) blocking the default WireGuard UDP port.

Analysis:

Control Plane (TCP/WebSocket): The web UI shows the client as "Online" because the control channel uses WebSocket (likely over TCP 443/80), which is not blocked.

Data Plane (UDP/WireGuard): The actual traffic tunnel relies on WireGuard, which defaults to UDP 51820. My packet capture confirms that the WireGuard handshake is being dropped by the firewall.

Evidence (tcpdump): I captured the traffic on the client side. The logs show repeated Handshake Initiation packets (length 148) being sent to the server's port 51820, but zero response packets are received. The connection is completely blocked at the network level.

Plaintext

Client sending Handshake Initiation (Length 148) every 5 seconds

18:09:00.858 IP 192.168.x.x.21456 > [Server_IP].51820: UDP, length 148
18:09:05.859 IP 192.168.x.x.21456 > [Server_IP].51820: UDP, length 148
18:09:10.860 IP 192.168.x.x.21456 > [Server_IP].51820: UDP, length 148

Result: Only OUT packets, no IN packets.

Conclusion: The "Gateway Timeout" occurs because the UDP tunnel never successfully establishes, despite the WebSocket being connected. The "ICMP ping timeout" in the logs is a symptom of the broken tunnel.

Recommendations:

User-side Workaround (Proxy): Since changing ports is often insufficient against protocol detection, it is recommended to run the newt client behind a proxy or VPN software (e.g., using a transparent proxy or a router-level tunnel) to encapsulate the UDP traffic and bypass the block.

Feature Request (Obfuscation / TCP Fallback): In high-censorship regions (like China), raw WireGuard protocol is easily identified and blocked. I strongly suggest the project consider adding a TCP fallback mode or UDP obfuscation (similar to udp2raw) functionality. This would allow the tunnel to survive in restrictive network environments where UDP is throttled or blocked.

<!-- gh-comment-id:3701935200 --> @Transwarpcom commented on GitHub (Dec 31, 2025): I have identified the root cause. This is not a bug in the software, but a network censorship issue (GFW in Mainland China) blocking the default WireGuard UDP port. Analysis: Control Plane (TCP/WebSocket): The web UI shows the client as "Online" because the control channel uses WebSocket (likely over TCP 443/80), which is not blocked. Data Plane (UDP/WireGuard): The actual traffic tunnel relies on WireGuard, which defaults to UDP 51820. My packet capture confirms that the WireGuard handshake is being dropped by the firewall. Evidence (tcpdump): I captured the traffic on the client side. The logs show repeated Handshake Initiation packets (length 148) being sent to the server's port 51820, but zero response packets are received. The connection is completely blocked at the network level. Plaintext # Client sending Handshake Initiation (Length 148) every 5 seconds 18:09:00.858 IP 192.168.x.x.21456 > [Server_IP].51820: UDP, length 148 18:09:05.859 IP 192.168.x.x.21456 > [Server_IP].51820: UDP, length 148 18:09:10.860 IP 192.168.x.x.21456 > [Server_IP].51820: UDP, length 148 # Result: Only OUT packets, no IN packets. Conclusion: The "Gateway Timeout" occurs because the UDP tunnel never successfully establishes, despite the WebSocket being connected. The "ICMP ping timeout" in the logs is a symptom of the broken tunnel. Recommendations: User-side Workaround (Proxy): Since changing ports is often insufficient against protocol detection, it is recommended to run the newt client behind a proxy or VPN software (e.g., using a transparent proxy or a router-level tunnel) to encapsulate the UDP traffic and bypass the block. Feature Request (Obfuscation / TCP Fallback): In high-censorship regions (like China), raw WireGuard protocol is easily identified and blocked. I strongly suggest the project consider adding a TCP fallback mode or UDP obfuscation (similar to udp2raw) functionality. This would allow the tunnel to survive in restrictive network environments where UDP is throttled or blocked.
Author
Owner

@sagehou commented on GitHub (Jan 30, 2026):

Same issue, this feature request (Obfuscation / TCP Fallback) seems to be the key.

<!-- gh-comment-id:3822212343 --> @sagehou commented on GitHub (Jan 30, 2026): Same issue, this feature request (Obfuscation / TCP Fallback) seems to be the key.
Sign in to join this conversation.
1 Participants
Notifications
Due Date
No due date set.
Dependencies

No dependencies set.

Reference: github-starred/pangolin#2091