searxng
searxng copied to clipboard
searxng
SearXNG sometimes redirects to main page without query
See: https://github.com/libredirect/browser_extension/issues/880
Problem encountered in Firefox extension Libredirect, but they believe this is SearXNG's problem.
It's possible that something does not work great with the anti bot protection.
Can't reproduce the issue with my instance https://darmarit.org/searx/ or https://paulgo.io/ you mentioned in https://github.com/libredirect/browser_extension/issues/880#issuecomment-1899420751 .. not sure what the issue is you have.
I can say for sure that this is not an issue with libredirect. It has happened to me on some occasions, and i do not have this extension.
i don't know how to reproduce it unfortunately. it just happened to me on my private instance a few moments ago. it usually does not happen. seems very random.
Happens to me with enough frequency to be annoying (about once a week). Both when I search using Firefox opensearch (no extensions), and when I use a redirect on iOS safari. It seems to happen with about the same frequency with both access methods.
The only other variables for me are my DNS provider (cloudflare, on which I have proxy turned off), and nginx being my reverse proxy. But I'm not sure if the problem lies with either of those.
I will try searching directly from the search home page for a while to see if it still occurs.
I have the same problem. I testes a lot of instances from https://searx.space/ and it happens randomly. I tried it with different browsers and devices and can't resolve it. I don't have any special plugins or extensions installed.
- https://github.com/searxng/searxng/discussions/3219
@MadAim123 do you have the same issue on my instance? https://darmarit.org/searx/search?q=test&language=de&safesearch=0&categories=general&time_range=month
@return42 when I tested it now (Firefox, Ege, Chrome on Windows), I can't reproduce it. But it happens randomly. So maybe it would happen tomorrow or in 2 weeks - or maybe not. Did you changed something in routing? Or do you use vanilla?
Vanilla installed by the scripts ..
./utils/searxng.sh install all
./utils/searxng.sh install apache
Not sure its related .. I'm using apache .. AFAIK the docker images are using caddy
@return42 I tried it now, after closing my browser after 1 hour and it happend with your instance too. I klicked on your link (https://darmarit.org/searx/search?q=test&language=de&safesearch=0&categories=general&time_range=month) and was redirected to https://darmarit.org/searx/
When I click another time, I was shown the results and I'm not redirected to the startpage.
With: Firefox, Windows. No extra installed Plugins, no extensions, Cookies are saved, jacascript is enabled.
Its a pity, I can't reproduce this issue ..
Cookies are saved
Did you saved some SearXNG preferences? if so, what prefs .. I am still looking for clues .. may this is related?
@return42 what are the possible ways that the anti bot may force a redirect?
I can only see that it's the case when there are too many requests: https://github.com/searxng/searxng/blob/08e524fc35d382e51725c2778fc97615851b8bc2/searx/botdetection/ip_limit.py#L126
what are the possible ways that the anti bot may force a redirect?
good point :+1: / haven't in mind -->
https://github.com/searxng/searxng/blob/c197c0e35e6eaa823d6ba8606df4e5a5c598a07b/searx/botdetection/ip_limit.py#L126
This redirects a browser to the index page / for cases in which (for whatever reasons) the browser has not requested the CSS-ping.
The index page is not in the bot detection and can be loaded even the IP has to many counts in the ip_limit.SUSPICIOUS_IP_WINDOW time window.
When the index page is loaded by the browser, the browser will send a CSS-ping request ..
https://github.com/searxng/searxng/blob/c197c0e35e6eaa823d6ba8606df4e5a5c598a07b/searx/botdetection/ip_limit.py#L113-L118
and the ip_limit.SUSPICIOUS_IP_WINDOW time window for this IP will be dropped.
This method is intended to ensure that a normal user is never blocked, even if his IP (for unknown reasons) has had too many accesses in the time window ip_limit.SUSPICIOUS_IP_WINDOW the window will be dropped when the index page is loaded.
One reason why a normal user ends up in the time window may be that requests are still coming from the same subnet that do not trigger a CSS ping request. Example: there is a bot and a normal user in the subnet ... then the normal user should not be blocked, even if we have to let the bot pass.
I'll have to analyze this in more detail ... the key is generated here
https://github.com/searxng/searxng/blob/c197c0e35e6eaa823d6ba8606df4e5a5c598a07b/searx/botdetection/link_token.py#L117-L127
And its lifetime is:
https://github.com/searxng/searxng/blob/c197c0e35e6eaa823d6ba8606df4e5a5c598a07b/searx/botdetection/link_token.py#L61-L62
Did you saved some SearXNG preferences? if so, what prefs .. I am still looking for clues .. may this is related?
For what it's worth, my browser with Libredirect extension has forgetful settings (no cookies, cache, site data saved), all is lost on browser quit and I still experienced the issue on SearXNG instances that I visit for the first time in current session.
If additional information is required for this bug I should be able to assist. I'm having a similar issue, except that it occurs on every search. My setup is as follows: I have two instances of sear-xng running. One on an unraid machine and the other on a raspberry pi. I have a local reverse proxy setup for failover.
If I directly connect to the specific searXNG instances I have no issues. Searching works as expected. However if I use the reverse proxy address my searches always redirect to the home page in Firefox. This issue persists on a macbook as well as a windows 11 machine. Using the exact same setup I don't have any issues using a chrome instance.
If it's personal usage you shouldn't have the anti bot features enabled.
It's not useful.
If it's personal usage you shouldn't have the anti bot features enabled.
It's not useful.
I don't believe that is my issue. Don't have any rate limiters enabled that I know of and the config shows it disabled in the docker.