Repository navigation
Title: Hiddify Manager 14.0.5 – REALITY verification failed and Firewall errors #5653
Description
Hello Hiddify Team,
I use Hiddify Manager 14.0.5 on an Aeza VPS (Ubuntu 24.04, Sweden, IP: 193.188.21.161).
Previously, VLESS VPN worked reliably on Windows and Android. First, the Android connection stopped working, while Windows continued working. Later, Windows also lost connectivity.
I reinstalled Hiddify Manager, but the problems remain.
Errors:
- "reality verification failed"
- "Finished with errors in: Firewall"
- TCP port 443 is listening, but connections from my home network (Rostelecom, Russia) time out.
- Hiddify 5.0.2 (sing-box): 0/2 REALITY configurations working.
- Xray 26.3.27: 5/11 configurations working, mainly VLESS HTTP transport.
Additional findings:
- DNS resolution works.
- The server is running, and firewall rules appear to allow TCP port 443.
- Hiddify successfully generates subscription links.
- Some subscription URLs have certificate verification issues.
- HAProxy previously experienced repeated crashes, possibly related to HTTP/3/QUIC.
My questions:
- What is causing the REALITY verification failure?
- Why does Hiddify report Firewall errors despite TCP port 443 being allowed?
- Could this be a compatibility issue between Hiddify Manager, sing-box and Xray?
- How can I restore stable VPN connectivity without reinstalling the server again?
Please help identify the root cause and recommend a safe solution.
Thank you for your assistance.
Activity
hiddify-com commentedon Oct 27, 2026
Thanks for the detailed report. To narrow this down, could you please share:
/opt/hiddify-manager/log/system/).systemctl status hiddify-haproxy hiddify-xray hiddify-singbox --no-pagerand the last ~100 lines of their logs (journalctl -u hiddify-xray -n 100 --no-pager, etc.).curl -vI https://<sni>).Note that connections timing out from a specific ISP while the port is listening is often caused by network-level filtering of the server IP rather than a panel problem, so it would also help to know whether the configs work from a different network.
moserzh7-sketch commentedon Oct 27, 2026
Subject: Hiddify Manager 14.0.5 — Firewall Installation Failure (Missing Docker Chains) and TCP/443 Connectivity Issues
Hello Hiddify Team,
Thank you for your response and for requesting additional diagnostic information.
I have completed further troubleshooting and identified the exact error responsible for the Firewall installation failure.
Below is a detailed report of the findings.
The relevant installation log was located at:
"/opt/hiddify-manager/data/log/reboot.log"
The previously suggested directory "/opt/hiddify-manager/log/system/" does not exist in this installation.
The log contains the following errors:
===run.sh services/firewall
ip6tables-restore v1.8.10 (nf_tables):
Chain 'DOCKER' does not exist
Error occurred at line: 123
iptables-restore v1.8.10 (nf_tables):
Chain 'DOCKER' does not exist
Error occurred at line: 129
services/firewall failed (exit code 2)
These steps reported an error: Firewall
Finished with errors in: Firewall (see the log above)
The firewall restoration process failed because the rules referenced Docker chains that were not available at the time.
Command executed:
"systemctl is-active docker; iptables -S DOCKER; ip6tables -S DOCKER"
Output:
active
-N DOCKER
-A DOCKER ! -i docker0 -o docker0 -j DROP
-N DOCKER
Docker is currently active, and the required chains exist.
This suggests a possible service initialization-order problem, a race condition, or an incompatibility involving iptables-nft and the Hiddify firewall restoration process.
However, the exact root cause has not yet been confirmed.
The following services are running:
The "hiddify-singbox.service" unit was not found.
Xray version: 26.3.27.
HAProxy version: 3.4.5.
Xray starts successfully but produces deprecation warnings for several transport protocols, including gRPC, WebSocket, HTTPUpgrade, and certain Trojan configurations.
The logs also contain a warning about REALITY listeners using ports other than 443.
HAProxy loads its configuration successfully.
The latest visible journal includes a controlled service restart and warnings about running as root without chroot, experimental directives, and the stats proxy logging configuration.
No recurrence of the previously reported HTTP/3/QUIC crash was visible in the latest journal excerpt.
Command:
"ss -lntp | grep ':443'"
Output:
LISTEN 0 4096 0.0.0.0:443 0.0.0.0:* users:(("rpxy-14",pid=992,fd=8))
LISTEN 0 4096 [::]:443 [::]:* users:(("rpxy-14",pid=992,fd=9))
The TCP listener is active on both IPv4 and IPv6.
Command:
"iptables -L INPUT -n -v --line-numbers"
Findings:
From Windows through Rostelecom, with VPN disabled:
"Test-NetConnection 193.188.21.161 -Port 443"
Output:
PingSucceeded : False
TcpTestSucceeded : False
This result was reproduced multiple times.
I ran:
"timeout 30 tcpdump -ni any 'tcp dst port 443'"
During one 30-second capture, 15 packets were received from external IP addresses, including 69.164.217.245.
The server is therefore receiving at least some inbound TCP/443 traffic.
However, the capture did not conclusively identify the Rostelecom client's packets, because the client's public source IP was not recorded.
This makes upstream filtering or routing problems a plausible explanation, but not yet a confirmed diagnosis.
The REALITY server name previously identified in the configuration is:
"msn.com"
The server-side reachability check:
"curl -vI https://msn.com"
has not yet been performed, so I cannot provide a verified result.
Could you please clarify the following?
I have already reinstalled Hiddify Manager once, but this did not restore connectivity.
I would prefer to avoid another reinstallation unless absolutely necessary.
I can provide the full sanitized installation log, service journals, and additional packet captures if required.
Thank you for your assistance and for maintaining Hiddify.
moserzh7-sketch commentedon Oct 28, 2026
Hello Hiddify Team,
I have now completed the remaining REALITY SNI connectivity test directly from my Aeza VPS.
Command:
curl -vI --max-time 15 https://msn.comResults:
msn.com.HTTP/2 301.https://www.msn.com/.Therefore, the configured REALITY SNI hostname is reachable from the VPS over HTTPS, and TLS certificate verification succeeds.
However, TCP/443 connections from Rostelecom in Russia still fail, while the server-side listener remains active.
Could you please review the firewall diagnostics and advise whether the remaining problem is likely related to Hiddify configuration or upstream network filtering?
Thank you.