With servers like mine connections go out through a system of outbound proxies I control, via a Tor hidden service. This sounds straightforward, but on servers like mine Tor access is provided via a transport system which is used as an internet gateway on a private LAN network. Keep in mind that Tor connections in general involve their own chaos and increased failure rate. Principles of isolation mean that clients using this transproxy cannot get any information via Tor's control interface on why a connection failed, as this would breach the isolation provided in principle.
Access to third party clearnet services is itself provided by servers running Tor, which creates hidden services that point to a SOCKS proxy. Systems on the private LAN behind the Tor transproxy, run their own transproxy with firewall rules which send things to it when the IP address is a regular Internet one and such. My point being that overall there are many places that things can go wrong when software on a server tries to reach clearnet services like xmrchain.net and the like. This information I hope illustrates that there are a lot of points of failures for any single HTTP request here.
As things are there is little information about why something might have failed when they do. My feature request is some optional logging built into the MoneroWP's code such as the class Monero_Explorer_Tools so that if a HTTP request fails, that the reasons for this and the time it is happening to the database. This would also mean a tool needs to exist for viewing these logs. With logs about this, the time they happened and such might point to useful information in logs for Tor and other things, and make diagnosing these issues easier.
At the moment some of my customers are having issues sometimes where these requests to third party services fail. Yet, whenever I am here the issues are never there in my own testing. I am kept in the dark about why they fail when they do, which leaves me without much fuel for thought on how I can improve things.
With servers like mine connections go out through a system of outbound proxies I control, via a Tor hidden service. This sounds straightforward, but on servers like mine Tor access is provided via a transport system which is used as an internet gateway on a private LAN network. Keep in mind that Tor connections in general involve their own chaos and increased failure rate. Principles of isolation mean that clients using this transproxy cannot get any information via Tor's control interface on why a connection failed, as this would breach the isolation provided in principle.
Access to third party clearnet services is itself provided by servers running Tor, which creates hidden services that point to a SOCKS proxy. Systems on the private LAN behind the Tor transproxy, run their own transproxy with firewall rules which send things to it when the IP address is a regular Internet one and such. My point being that overall there are many places that things can go wrong when software on a server tries to reach clearnet services like
xmrchain.netand the like. This information I hope illustrates that there are a lot of points of failures for any single HTTP request here.As things are there is little information about why something might have failed when they do. My feature request is some optional logging built into the MoneroWP's code such as the class
Monero_Explorer_Toolsso that if a HTTP request fails, that the reasons for this and the time it is happening to the database. This would also mean a tool needs to exist for viewing these logs. With logs about this, the time they happened and such might point to useful information in logs for Tor and other things, and make diagnosing these issues easier.At the moment some of my customers are having issues sometimes where these requests to third party services fail. Yet, whenever I am here the issues are never there in my own testing. I am kept in the dark about why they fail when they do, which leaves me without much fuel for thought on how I can improve things.