starred/whoogle-search
1
0
Fork 0
mirror of https://github.com/benbusby/whoogle-search.git synced 2026-04-25 12:15:50 +03:00
Code Issues 9 Projects Releases Packages Wiki Activity

[GH-ISSUE #26] [BUG] Whoogle-Search doesn't work behind Apache2 reverse proxy #21

New issue
Closed
opened 2026-02-25 20:34:41 +03:00 by kerem · 13 comments
kerem commented 2026-02-25 20:34:41 +03:00
Owner
Copy link

Originally created by @lol7344 on GitHub (May 11, 2020).
Original GitHub issue: https://github.com/benbusby/whoogle-search/issues/26

Originally assigned to: @benbusby on GitHub.

Describe the bug
Whoogle Search is unable to work behing an Apache2 reverse proxy, and it only works when started up by explicitly telling it to run on the external IP (else, it tries to run locally on 127.0.0.1, denying any external request).

To Reproduce
Steps to reproduce the behavior:

  1. Install whoogle-search via pip
  2. Make an apache2 reverse proxy, using a config like this:
<VirtualHost *:443>
    ServerName search.domain.com

    ProxyRequests Off
    ProxyPreserveHost On
    ProxyVia Full
    <Proxy *>
       Require all granted
    </Proxy>

    ProxyPass "/" "http://127.0.0.1:8888"
    ProxyPassReverse "/" "http://127.0.0.1:8888"

    Include <removed>
    SSLCertificateFile <removed>
    SSLCertificateKeyFile <removed>
</VirtualHost>
  1. Enable website with a2ensite
  2. Restart apache2
  3. Start whoogle with whoogle-search

Expected behavior
Whoogle homepage should load correctly. However, all I get is a blank page.
The server logs only show this:

 * Serving Flask app "app" (lazy loading)
 * Environment: production
   WARNING: This is a development server. Do not use it in a production deployment.
   Use a production WSGI server instead.
 * Debug mode: off
 * Running on http://127.0.0.1:8888/ (Press CTRL+C to quit)
127.0.0.1 - - [12/May/2020 00:32:34] "GET / HTTP/1.1" 200 -
127.0.0.1 - - [12/May/2020 00:32:37] "GET / HTTP/1.1" 200 -

Showing that requests are indeed coming, however from IP 127.0.0.1, which is the localhost of the server.

If I run whoogle-search by using the same default command, "whoogle-search", and I try accessing it directly from IP:port, I am unable to even reach it and the console doesn't log anything.

The only way I have to access the homepage is by using whoogle-search --host 149.XX.YY.Z and then directly accessing it in the browser via IP:port. Then, the console shows correct info:

 * Serving Flask app "app" (lazy loading)
 * Environment: production
   WARNING: This is a development server. Do not use it in a production deployment.
   Use a production WSGI server instead.
 * Debug mode: off
 * Running on http://149.XX.YY.Z:8888/ (Press CTRL+C to quit)
84.17.YY.XX - - [12/May/2020 00:39:24] "GET / HTTP/1.1" 200 -
84.17.YY.XX - - [12/May/2020 00:39:24] "GET /static/js/controller.js HTTP/1.1" 200 -
84.17.YY.XX - - [12/May/2020 00:39:24] "GET /static/css/main.css HTTP/1.1" 200 -
84.17.YY.XX - - [12/May/2020 00:39:24] "GET /static/img/logo.png HTTP/1.1" 200 -
84.17.YY.XX - - [12/May/2020 00:39:24] "GET /config HTTP/1.1" 200 -
84.17.YY.XX - - [12/May/2020 00:39:24] "GET /static/img/favicon/favicon-32x32.png HTTP/1.1" 200 -
84.17.YY.XX - - [12/May/2020 00:39:24] "GET /static/img/favicon/android-icon-192x192.png HTTP/1.1" 200 -

Desktop (please complete the following information):

  • OS: Ubuntu 20.04
  • Browser: Chrome and Firefox
Originally created by @lol7344 on GitHub (May 11, 2020). Original GitHub issue: https://github.com/benbusby/whoogle-search/issues/26 Originally assigned to: @benbusby on GitHub. **Describe the bug** Whoogle Search is unable to work behing an Apache2 reverse proxy, and it only works when started up by explicitly telling it to run on the external IP (else, it tries to run locally on 127.0.0.1, denying any external request). **To Reproduce** Steps to reproduce the behavior: 1. Install whoogle-search via pip 2. Make an apache2 reverse proxy, using a config like this: ``` <VirtualHost *:443> ServerName search.domain.com ProxyRequests Off ProxyPreserveHost On ProxyVia Full <Proxy *> Require all granted </Proxy> ProxyPass "/" "http://127.0.0.1:8888" ProxyPassReverse "/" "http://127.0.0.1:8888" Include <removed> SSLCertificateFile <removed> SSLCertificateKeyFile <removed> </VirtualHost> ``` 3. Enable website with a2ensite 4. Restart apache2 5. Start whoogle with `whoogle-search` **Expected behavior** Whoogle homepage should load correctly. However, all I get is a blank page. The server logs only show this: ``` * Serving Flask app "app" (lazy loading) * Environment: production WARNING: This is a development server. Do not use it in a production deployment. Use a production WSGI server instead. * Debug mode: off * Running on http://127.0.0.1:8888/ (Press CTRL+C to quit) 127.0.0.1 - - [12/May/2020 00:32:34] "GET / HTTP/1.1" 200 - 127.0.0.1 - - [12/May/2020 00:32:37] "GET / HTTP/1.1" 200 - ``` Showing that requests are indeed coming, however from IP 127.0.0.1, which is the localhost of the server. If I run whoogle-search by using the same default command, "whoogle-search", and I try accessing it directly from IP:port, I am unable to even reach it and the console doesn't log anything. The only way I have to access the homepage is by using `whoogle-search --host 149.XX.YY.Z` and then directly accessing it in the browser via IP:port. Then, the console shows correct info: ``` * Serving Flask app "app" (lazy loading) * Environment: production WARNING: This is a development server. Do not use it in a production deployment. Use a production WSGI server instead. * Debug mode: off * Running on http://149.XX.YY.Z:8888/ (Press CTRL+C to quit) 84.17.YY.XX - - [12/May/2020 00:39:24] "GET / HTTP/1.1" 200 - 84.17.YY.XX - - [12/May/2020 00:39:24] "GET /static/js/controller.js HTTP/1.1" 200 - 84.17.YY.XX - - [12/May/2020 00:39:24] "GET /static/css/main.css HTTP/1.1" 200 - 84.17.YY.XX - - [12/May/2020 00:39:24] "GET /static/img/logo.png HTTP/1.1" 200 - 84.17.YY.XX - - [12/May/2020 00:39:24] "GET /config HTTP/1.1" 200 - 84.17.YY.XX - - [12/May/2020 00:39:24] "GET /static/img/favicon/favicon-32x32.png HTTP/1.1" 200 - 84.17.YY.XX - - [12/May/2020 00:39:24] "GET /static/img/favicon/android-icon-192x192.png HTTP/1.1" 200 - ``` **Desktop (please complete the following information):** - OS: Ubuntu 20.04 - Browser: Chrome and Firefox
kerem 2026-02-25 20:34:41 +03:00
  • closed this issue
  • added the
    bug
         label
kerem commented 2026-02-25 20:34:42 +03:00
Author
Owner
Copy link

@benbusby commented on GitHub (May 12, 2020):

Interesting. I don't use Apache often, but I have it running on an Nginx reverse proxy at the moment and it works properly, and the proxy config looks about the same between our two setups. I'll spin up an Apache proxy sometime this week and see what's going on. Thanks for reporting!

<!-- gh-comment-id:627055327 --> @benbusby commented on GitHub (May 12, 2020): Interesting. I don't use Apache often, but I have it running on an Nginx reverse proxy at the moment and it works properly, and the proxy config looks about the same between our two setups. I'll spin up an Apache proxy sometime this week and see what's going on. Thanks for reporting!
kerem commented 2026-02-25 20:34:42 +03:00
Author
Owner
Copy link

@FoxxMD commented on GitHub (May 12, 2020):

Can confirm whoogle works fine behind reverse proxy for me. Running on docker with nginx using a pretty straight-forward configuration

server {
	listen 443 ssl http2;
	server_name myserver.name;
	
        include /config/nginx/sub-strong-ssl.conf;
	
	location / {
        include /config/nginx/proxy.conf;
        proxy_pass         http://hostIP:hostPort/;
  }
}
<!-- gh-comment-id:627510180 --> @FoxxMD commented on GitHub (May 12, 2020): Can confirm whoogle works fine behind reverse proxy for me. Running on docker with nginx using a pretty straight-forward configuration ``` server { listen 443 ssl http2; server_name myserver.name; include /config/nginx/sub-strong-ssl.conf; location / { include /config/nginx/proxy.conf; proxy_pass http://hostIP:hostPort/; } } ```
kerem commented 2026-02-25 20:34:42 +03:00
Author
Owner
Copy link

@lol7344 commented on GitHub (May 12, 2020):

Interesting. I don't use Apache often, but I have it running on an Nginx reverse proxy at the moment and it works properly, and the proxy config looks about the same between our two setups. I'll spin up an Apache proxy sometime this week and see what's going on. Thanks for reporting!

Thanks! I have also tried mixing those settings up, but both ProxyRequests and ProxyPreserveHost do not change anything. The last one should forward the client's IP to the running app, instead of the standard 127.0.0.1 which programs behind reverse proxies usually receive, however whoogle still seems to be logging it as localhost.
I'm not sure if this is a misconfiguration or a bug tho... I have many other services running behind the very same config "preset" and they work flawlessly.

Can confirm whoogle works fine behind reverse proxy for me. Running on docker with nginx using a pretty straight-forward configuration

server {
	listen 443 ssl http2;
	server_name myserver.name;
	
        include /config/nginx/sub-strong-ssl.conf;
	
	location / {
        include /config/nginx/proxy.conf;
        proxy_pass         http://hostIP:hostPort/;
  }
}

Just to investigate a little: are you starting up whoogle by using whoogle-search --host hostIP or without any args? Because unless I start it up by explicitly telling the public IP of the server, I am unable to access it, as it only accepts requests made on 127.0.0.1 which, however, is the localhost.

<!-- gh-comment-id:627643256 --> @lol7344 commented on GitHub (May 12, 2020): > > > Interesting. I don't use Apache often, but I have it running on an Nginx reverse proxy at the moment and it works properly, and the proxy config looks about the same between our two setups. I'll spin up an Apache proxy sometime this week and see what's going on. Thanks for reporting! Thanks! I have also tried mixing those settings up, but both `ProxyRequests` and `ProxyPreserveHost` do not change anything. The last one should forward the client's IP to the running app, instead of the standard 127.0.0.1 which programs behind reverse proxies usually receive, however whoogle still seems to be logging it as localhost. I'm not sure if this is a misconfiguration or a bug tho... I have many other services running behind the very same config "preset" and they work flawlessly. > > > Can confirm whoogle works fine behind reverse proxy for me. Running on docker with nginx using a pretty straight-forward configuration > > ``` > server { > listen 443 ssl http2; > server_name myserver.name; > > include /config/nginx/sub-strong-ssl.conf; > > location / { > include /config/nginx/proxy.conf; > proxy_pass http://hostIP:hostPort/; > } > } > ``` Just to investigate a little: are you starting up whoogle by using `whoogle-search --host hostIP` or without any args? Because unless I start it up by explicitly telling the public IP of the server, I am unable to access it, as it only accepts requests made on 127.0.0.1 which, however, is the localhost.
kerem commented 2026-02-25 20:34:42 +03:00
Author
Owner
Copy link

@FoxxMD commented on GitHub (May 13, 2020):

Starting without arguments

<!-- gh-comment-id:627957579 --> @FoxxMD commented on GitHub (May 13, 2020): Starting without arguments
kerem commented 2026-02-25 20:34:42 +03:00
Author
Owner
Copy link

@urlyb commented on GitHub (May 17, 2020):

Additionally, there is a problem if you want to proxy requests for example from https://somedomain.com/whoogle to whoogle server in backend. I'm not familiar with flask, but I think this might help - https://pypi.org/project/flask-reverse-proxy-fix/.

Also, for this to work, all leading slashes in URLs in templates (and possibly elsewhere) should be removed.

For example href="/static/img/favicon/apple-icon-57x57.png" should be changed to href="static/img/favicon/apple-icon-57x57.png"...

<!-- gh-comment-id:629863988 --> @urlyb commented on GitHub (May 17, 2020): Additionally, there is a problem if you want to proxy requests for example from https://somedomain.com/whoogle to whoogle server in backend. I'm not familiar with flask, but I think this might help - https://pypi.org/project/flask-reverse-proxy-fix/. Also, for this to work, all leading slashes in URLs in templates (and possibly elsewhere) should be removed. For example href="/static/img/favicon/apple-icon-57x57.png" should be changed to href="static/img/favicon/apple-icon-57x57.png"...
kerem commented 2026-02-25 20:34:42 +03:00
Author
Owner
Copy link

@danielbyon commented on GitHub (May 19, 2020):

I'm having issues with running behind an nginx server subdomain proxying to a docker-compose container. With my setup, when I manually navigate to "search.mydomain.net", I can get to my whoogle page, and searching for something works. But when I use the Firefox (on macOS) search engine (setup using the three-dots and "add search engine") it tries to navigate to https://0.0.0.0:5000/search, which fails.

I've tried setting the root URL to my subdomain URL in the configuration section, but that didn't work.

<!-- gh-comment-id:630563635 --> @danielbyon commented on GitHub (May 19, 2020): I'm having issues with running behind an nginx server subdomain proxying to a docker-compose container. With my setup, when I manually navigate to "search.mydomain.net", I can get to my whoogle page, and searching for something works. But when I use the Firefox (on macOS) search engine (setup using the three-dots and "add search engine") it tries to navigate to `https://0.0.0.0:5000/search`, which fails. I've tried setting the root URL to my subdomain URL in the configuration section, but that didn't work.
kerem commented 2026-02-25 20:34:42 +03:00
Author
Owner
Copy link

@benbusby commented on GitHub (May 19, 2020):

@danielbyon after you updated the root URL to your subdomain, did you remove and re-add the search engine from your Firefox preferences? Firefox saves the opensearch.xml template as-is once it's generated and added, so any changes to root URL won't be reflected unless it's removed first. If you already tried that though, let me know and I'll look into it. Either way probably warrants updating the README, since this isn't the first time this has happened.

@urlyb I haven't encountered this yet on my reverse proxy, but it seems like something that could be handled with the right nginx config rather than adding in another library. That being said though, I'm still planning on recreating my full setup for both apache and nginx and adding that to the README soon to hopefully clear up any confusion.

<!-- gh-comment-id:630923243 --> @benbusby commented on GitHub (May 19, 2020): @danielbyon after you updated the root URL to your subdomain, did you remove and re-add the search engine from your Firefox preferences? Firefox saves the opensearch.xml template as-is once it's generated and added, so any changes to root URL won't be reflected unless it's removed first. If you already tried that though, let me know and I'll look into it. Either way probably warrants updating the README, since this isn't the first time this has happened. @urlyb I haven't encountered this yet on my reverse proxy, but it seems like something that could be handled with the right nginx config rather than adding in another library. That being said though, I'm still planning on recreating my full setup for both apache and nginx and adding that to the README soon to hopefully clear up any confusion.
kerem commented 2026-02-25 20:34:42 +03:00
Author
Owner
Copy link

@danielbyon commented on GitHub (May 20, 2020):

Yes that worked, thanks! And a README update would be good

<!-- gh-comment-id:631156246 --> @danielbyon commented on GitHub (May 20, 2020): Yes that worked, thanks! And a README update would be good
kerem commented 2026-02-25 20:34:42 +03:00
Author
Owner
Copy link

@benbusby commented on GitHub (May 22, 2020):

@lol7344 sorry for the delay, I just now got around to setting up an apache reverse proxy. It looks like your config has at least one parameter that is blocking static content from being served properly, which is why you're only seeing a blank page with your setup. Under your browser's network tab you should see either 404 or 502 errors returned for all content besides just the base index.html.

Here's the simple reverse proxy config I set up that works fine:

<VirtualHost *:80>
	ServerName search.domain.com
	
	ProxyRequests Off
	ProxyPreserveHost On
	ProxyPass / http://127.0.0.1:5000/
	ProxyPassReverse / http://127.0.0.1:5000/
</VirtualHost>

I didn't go through in depth with your setup to figure out what was wrong, but setting up an instance from scratch with these options works for me. Though from what I briefly saw when looking into available apache reverse proxy settings, it seemed like your setup may have contained configuration settings for both reverse proxies and forward proxies (namely the <Proxy "*"> ... </Proxy> block, which from what I can tell is only used for forwarding proxies to alternate hosts).

Let me know if this works for you! I'll close the issue for now, but will keep monitoring the discussion here in case you run into any other issues.

<!-- gh-comment-id:632821988 --> @benbusby commented on GitHub (May 22, 2020): @lol7344 sorry for the delay, I just now got around to setting up an apache reverse proxy. It looks like your config has at least one parameter that is blocking static content from being served properly, which is why you're only seeing a blank page with your setup. Under your browser's network tab you should see either 404 or 502 errors returned for all content besides just the base `index.html`. Here's the simple reverse proxy config I set up that works fine: ``` <VirtualHost *:80> ServerName search.domain.com ProxyRequests Off ProxyPreserveHost On ProxyPass / http://127.0.0.1:5000/ ProxyPassReverse / http://127.0.0.1:5000/ </VirtualHost> ``` I didn't go through in depth with your setup to figure out what was wrong, but setting up an instance from scratch with these options works for me. Though from what I briefly saw when looking into available apache reverse proxy settings, it seemed like your setup may have contained configuration settings for both reverse proxies and forward proxies (namely the `<Proxy "*"> ... </Proxy>` block, which from what I can tell is only used for forwarding proxies to alternate hosts). Let me know if this works for you! I'll close the issue for now, but will keep monitoring the discussion here in case you run into any other issues.
kerem commented 2026-02-25 20:34:42 +03:00
Author
Owner
Copy link

@urlyb commented on GitHub (May 22, 2020):

@benbusby Did you by any chance test also the following Apache config:

<VirtualHost *:80>
 ServerName some.domain.com

 ProxyRequests Off
 ProxyPreserveHost On
 ProxyPass /search http://127.0.0.1:5000
 ProxyPassReverse /search http://127.0.0.1:5000
</VirtualHost>
<!-- gh-comment-id:632850932 --> @urlyb commented on GitHub (May 22, 2020): @benbusby Did you by any chance test also the following Apache config: ``` <VirtualHost *:80> ServerName some.domain.com ProxyRequests Off ProxyPreserveHost On ProxyPass /search http://127.0.0.1:5000 ProxyPassReverse /search http://127.0.0.1:5000 </VirtualHost> ```
kerem commented 2026-02-25 20:34:42 +03:00
Author
Owner
Copy link

@lol7344 commented on GitHub (May 22, 2020):

@lol7344 sorry for the delay, I just now got around to setting up an apache reverse proxy. It looks like your config has at least one parameter that is blocking static content from being served properly, which is why you're only seeing a blank page with your setup. Under your browser's network tab you should see either 404 or 502 errors returned for all content besides just the base index.html.

Here's the simple reverse proxy config I set up that works fine:

<VirtualHost *:80>
	ServerName search.domain.com
	
	ProxyRequests Off
	ProxyPreserveHost On
	ProxyPass / http://127.0.0.1:5000/
	ProxyPassReverse / http://127.0.0.1:5000/
</VirtualHost>

I didn't go through in depth with your setup to figure out what was wrong, but setting up an instance from scratch with these options works for me. Though from what I briefly saw when looking into available apache reverse proxy settings, it seemed like your setup may have contained configuration settings for both reverse proxies and forward proxies (namely the <Proxy "*"> ... </Proxy> block, which from what I can tell is only used for forwarding proxies to alternate hosts).

Let me know if this works for you! I'll close the issue for now, but will keep monitoring the discussion here in case you run into any other issues.

This configuration worked flawlessly. I have been copy-pasting the same config for a very long time without any issue and I forgot what half the stuff did, however it looks like my thinkering before opening this issue was not sufficient to indentify the problem.

I'm sorry for all the trobule caused, and thank you so much for gifting this precious project to the community! :)

<!-- gh-comment-id:632925028 --> @lol7344 commented on GitHub (May 22, 2020): > > > @lol7344 sorry for the delay, I just now got around to setting up an apache reverse proxy. It looks like your config has at least one parameter that is blocking static content from being served properly, which is why you're only seeing a blank page with your setup. Under your browser's network tab you should see either 404 or 502 errors returned for all content besides just the base `index.html`. > > Here's the simple reverse proxy config I set up that works fine: > > ``` > <VirtualHost *:80> > ServerName search.domain.com > > ProxyRequests Off > ProxyPreserveHost On > ProxyPass / http://127.0.0.1:5000/ > ProxyPassReverse / http://127.0.0.1:5000/ > </VirtualHost> > ``` > > I didn't go through in depth with your setup to figure out what was wrong, but setting up an instance from scratch with these options works for me. Though from what I briefly saw when looking into available apache reverse proxy settings, it seemed like your setup may have contained configuration settings for both reverse proxies and forward proxies (namely the `<Proxy "*"> ... </Proxy>` block, which from what I can tell is only used for forwarding proxies to alternate hosts). > > Let me know if this works for you! I'll close the issue for now, but will keep monitoring the discussion here in case you run into any other issues. This configuration worked flawlessly. I have been copy-pasting the same config for a very long time without any issue and I forgot what half the stuff did, however it looks like my thinkering before opening this issue was not sufficient to indentify the problem. I'm sorry for all the trobule caused, and thank you so much for gifting this precious project to the community! :)
kerem commented 2026-02-25 20:34:42 +03:00
Author
Owner
Copy link

@benbusby commented on GitHub (May 22, 2020):

@urlyb no, but that should just be a matter of writing the config file properly to source static files from wherever the repo was cloned. I'm not super familiar with apache configuration, but it shouldn't be too difficult -- just modifying your existing proxy setup to account for a leading /search should work.

<!-- gh-comment-id:632931483 --> @benbusby commented on GitHub (May 22, 2020): @urlyb no, but that should just be a matter of writing the config file properly to source static files from wherever the repo was cloned. I'm not super familiar with apache configuration, but it shouldn't be too difficult -- just modifying your existing proxy setup to account for a leading `/search` should work.
kerem commented 2026-02-25 20:34:42 +03:00
Author
Owner
Copy link

@bugbounce commented on GitHub (Oct 28, 2020):

I was unable to get the nginx reverse proxy when hosting on a subpath. From what I figured it was because of absolute links used in the HTML files. Have raised a PR https://github.com/benbusby/whoogle-search/pull/139

<!-- gh-comment-id:718071472 --> @bugbounce commented on GitHub (Oct 28, 2020): I was unable to get the nginx reverse proxy when hosting on a subpath. From what I figured it was because of absolute links used in the HTML files. Have raised a PR https://github.com/benbusby/whoogle-search/pull/139
Sign in to join this conversation.
No Branch/Tag specified
Branches Tags
main
dependabot/pip/python-dotenv-1.2.2
v1.2.4
v1.2.3
v1.2.2
v1.2.1-test
v1.1.2
v1.1.1-beta
v1.1.0
v1.1.0-beta
v1.0.0-beta
v0.9.4
v0.9.3
v0.9.2
v0.9.1
v0.9.0
v0.8.4
v0.8.3
v0.8.2
v0.8.1
v0.8.0
v0.7.4
v0.7.3
v0.7.2
v0.7.1
v0.7.0
v0.6.0
v0.5.4
v0.5.3
v0.5.2
v0.5.1
v0.5.0
v0.4.1
v0.4.0
v0.3.2
v0.3.1
v0.3.0
v0.2.1
0.2.0
v0.1.4
v0.1.3
v0.1.2
v0.1.1
v0.1.0
v0.0.1
Labels
Clear labels   
Fixed (Pending PR Merge)

   
Stale

   
bug

   
enhancement

   
enhancement

   
good first issue

   
help wanted

   
keep-open

   
needs more info

   
pull-request

Mirrored from GitHub Pull Request

  
question

   
theme

   
unfortunate
No labels
Fixed (Pending PR Merge)
Stale
bug
enhancement
enhancement
good first issue
help wanted
keep-open
needs more info
pull-request
question
theme
unfortunate
Milestone
Clear milestone
No items
No milestone
Projects
Clear projects
No items
No project
Assignees
Clear assignees
No assignees
1 participant
Notifications
Due date
The due date is invalid or out of range. Please use the format "yyyy-mm-dd".

No due date set.

Dependencies

No dependencies set.

Reference
starred/whoogle-search#21
No description provided.