404 errors don't occur if there's a "?" string appended to the URL.
Custom 404 Page by Siropu 1.2.0
- Thread starter Siropu
- Start date
Not yet. The Javascript based features won't work.
Siropu updated Custom 404 Page by Siropu with a new update entry:
Update for XenForo 2.3
Read the rest of this update entry...
Update for XenForo 2.3
Read the rest of this update entry...
It's worked for me, but media not redirected.
Hello. I just noticed that when you create a redirect i.e. https://www.example.com/news/ to https://www.example.com/new/... the redirect will only work if the URL has the trailing slash at the end. If it doesn't, then it won't work. For example https://www.example.com/news will throw a 404 not found. Could this be fixed please?
Sorry if this has been asked before: I installed this add on recently and am wondering why in most of the cases no source IP is in the log (while sometimes there is one - but only in maybe 1% of the cases if at all)?
Are the entries with IPs, for logged in members? That would be my guess.
Have you tried adding it without / or both?
It could be a bot/proxy that doesn't send any IP information.
How could that be? I'd have assumed that it is unavoidable to send the source IP given how TCP/IP works and apart from that: The IPs are logged in the server's web.log when you grep it with the URL that is noted in the log of the 404-add on. So they are there.
You can only add one redirect per 404. Adding it without the / will only account for the 404 without the /.
Bots can manipulate the headers used to get the user IP so they are not reliable.
I'm using XF's
getIp() method with $allowProxied set to true to get the IP so unless convertIpStringToBinary fails, which is used to get the value stored for the IP, what you see is what you get in the 404 logs.You can use the regex redirect admin option:
#^https?://www\.example\.com/news/?$#
Will I have to do this for every URL? I have a few and it would be tedious.
For the /route/ part, yes.
This goes beyond my knowledge and experience. I can only assume that the difference possibly might come from different layers: XF lives somewhat on the application layer wheras the webserver gets it information probably directly from the network layer. Spoofing a sender IP in TCP/IP does only make sense if you do not want to receive an answer, so mainly for DOS-attacks. The requests I am after are clearly eager for an answer: They call lists of potentially existing URLs in the hope to find something, they scan for things like /backups, /dev, /wp-includes/html-api/index.php, files under /wp-install etc.. So they do want an answer, however, it might make sense for them to garbadge the headers somwhat for the exact reason to poison logs on the application layer (if that's possible) in an attempt to hide themselves.
These fraudulent requests are however not the kind of requests your add on aims at, so clearly no failure on your side.
On a sidenote: Most of them come from Microsofts network range, so possibly these are azure accounts that could be cut off quickly by Microsoft in case attacks and frauds come from them and Microsoft gets notified. So it would make sense for the crackers to hide their IPs as good as possible to slow down the rate in which they have to switch their azure accounts and the (probably fake or stolen) identities and credit card details to open fresh ones and to rebuild their infrastructure.
Another big part of those requests currently comes from networks located in Africa (or rather network blocks that belong to Afrinic administration). ATM mainly from the network of a company with the trustworthy name "cheapy.host" - who do not seem to have a working homepage (any more) but still a (somewhat dead) facebook page.
Had a further look into it and apart from malicious bots also the bing bot it affected. I.e I had this call in the log that ended with a 404:
upper one:
msnbot-40-77-167-149.search.msn.com - - [08/Apr/2025:15:15:17 +0200] "GET /tags/start/ HTTP/1.1" 404 9472 "-" "Mozilla/5.0 AppleWebKit/537.36 (KHTML, like Gecko; compatible; bingbot/2.0; +http://www.bing.com/bingbot.htm) Chrome/116.0.1938.76 Safari/537.36" 315 10202
The URL "/tags/start/" exists (there is a tag "start"). It seems only accessble when you are logged in (which bingbot is not). If I call the URL when not logged in I do indeed get a 404 - a bit strange, I would have expected a 401 here. Clearly not your fault - rather a bug in XF that may impact SEO ranking to the negative (as bing will this way get hundreds of 404s on my forum)
second one:
msnbot-40-77-167-76.search.msn.com - - [08/Apr/2025:14:26:41 +0200] "GET /threads/Threadurl.1338/Picture-Name.jpg HTTP/1.1" 404 9505 "-" "Mozilla/5.0 AppleWebKit/537.36 (KHTML, like Gecko; compatible; bingbot/2.0; +http://www.bing.com/bingbot.htm) Chrome/116.0.1938.76 Safari/537.36" 796 14614
There are hundreds of those. The requested picture does exist (it is embedded in the thread) but as full size pictures are only accessible to logged in users the bot won't get the ful resolution pic. It would however have a different URL than the bot requested anyway - no idea where he got his from.
Anyway: This makes the log pretty useless as it is spoiled with 100s of entries caused by bing that can only manually be identified by grepping through the web.log.
Similar threads
