I have been using Gateone behind an Apache proxy for a long time. All of a sudden, probably after the last apt-get update/upgrade of my Debian Jessie install, this no longer works.
The error I get in the error.log is this :
[Sat Sep 12 16:20:47.992400 2015] [proxy:warn] [pid 1870] [client 192.168.0.2:5022] AH01144: No protocol handler was valid for the URL /gateone/. If you are using a DSO version of mod_proxy, make sure the proxy submodules are included in the configuration using LoadModule.
All answers I could find were pointing to a missing proxy (sub)module that needed to be loaded. This is the list of proxy modules I have loaded :
proxy.conf proxy_connect.load proxy_html.conf proxy_http.load
proxy.load proxy_html.load proxy_wstunnel.load
And the (unchanged) section in my http conf file looks like this :
ProxyPass /gateone/ ws://localhost:8888/gateone/
ProxyPassReverse /gateone/ ws://localhost:8888/gateone/
ProxyPass /gateone/ wss://localhost:8888/gateone/
ProxyPassReverse /gateone/ wss://localhost:8888/gateone/
ProxyPass /gateone/ http://localhost:8888/gateone/
ProxyPassReverse /gateone/ http://localhost:8888/gateone/
This configuration used to work. Can anyone please tell me if something has changed lately in Debian Jessie, especially regarding proxying (websockets proxying) ?
Thanks,
Hans
2.4.17 has this exact same problem but 2.4.12 was fine.
Interestingly this ALSO occurs on the 2.4.16 and 2.4.17 Windows x64 release using VC14 or VC11 so this is entirely something internal to the proxy modules.
The only resolution appears to be downgrading to 2.4.12 because there exists no combination of proxy modules to make it work and you can use your config in 2.4.12 without issue. Definite websocket proxy break 2.4.16+
*Update: Workaround allows http: fallback from ws: when you use ProxyPass with a very specific URL.
Eg.
#Works 2.4.12 but fails 2.4.16+
ProxyPass /ws/ ws://localhost:8080/ws/
#2.4.16+ seems to want full and exact path and ws: fails but http: failover works
ProxyPass /ws/stomp/ http://localhost:8080/ws/stomp/
Related
I've got a somewhat unique (maybe not, but unique to me) architecture here for some home apps that variously require PHP 5.6 and PHP 7.1. This is the architecture recommended to me by /r/docker:
One container acting as Apache Reverse Proxy that will ingest a DNS request on port 80 and then pass it to one of the below containers' ports.
One container running Apache with PHP 5.6, listening on port 8081.
One container running Apache with PHP 7.1, listening on port 8080.
I've been able to get domainname.com to work this way, by setting up the following domainname.com.conf in /etc/apache2/sites-available:
<VirtualHost *:80>
ServerName domainname.com
<Proxy *>
Allow from localhost
</Proxy>
ProxyPass "/" "http://public.ip.address:8080/" retry=0
ProxyPreserveHost On
</VirtualHost>
However, one of my subdomains needs to push to an application on the PHP 5.6 side. So I've set up this subdomain.domainname.com.conf:
<VirtualHost *:80>
ServerName subdomain.domainname.com
<Proxy *>
Allow from localhost
</Proxy>
ProxyPass "/" "http://public.ip.address:8081/subdomain/" retry=0
ProxyPreserveHost On
</VirtualHost>
Indeed, going directly to http://public.ip.address:8081/subdomain/ loads the application just fine, but for whatever reason, going to http://subdomain.domain.com gives a 503. Originally it was just showing the Apache on Ubuntu page, which is when I realized I needed to a2ensite and reload Apache, which has since been done.
The logs show this:
[Wed Jul 10 21:36:59.049131 2019] [proxy:error] [pid 2298:tid 139882856969984] (113)No route to host: AH00957: HTTP: attempt to connect to public.ip.address:8081 (3.220.176.240) failed
[Wed Jul 10 21:36:59.049182 2019] [proxy_http:error] [pid 2298:tid 139882856969984] [client 128.229.4.2:58611] AH01114: HTTP: failed to make connection to backend: public.ip.address
We know that the system can access 8080 just fine, so I'm not sure why it's struggling with this traffic. As mentioned above, hitting the ProxyPass URL directly from the outside loads the page fine, so traffic inbound to that container is fine. SELinux is disabled. This is in AWS and Security Groups are configured properly as far as I can tell (see: traffic works from outside).
Using the public IP address is the only way I've been able to get inter-container traffic to work, because using Docker's bridge IPs didn't work previously.
On the old system, when all my apps were just PHP 5.6, I had a standard VirtualHost statement that just took in the subdomain.domain.com and pointed it to a specific DocumentRoot. I can't do that here since the reverse proxy container needs to hand off the traffic to the container with the right PHP version.
Many thanks for any tips or tricks here.
I need to forward all traffic from specified port to a Unix Domain Socket in Apache:
In sites-enabled/000-default.conf I have defined a VirtualHost:
<VirtualHost *:8091>
ProxyRequests Off
<Proxy *>
Order deny,allow
Allow from all
</Proxy>
ProxyPass / unix:/var/lib/jenkins/workspace/myproject/mysocket.sock|http://127.0.0.1/
ProxyPassReverse / unix:/var/lib/jenkins/workspace/myproject/mysocket.sock|http://127.0.0.1/
</VirtualHost>
In ports.conf I have:
Listen 80
Listen 8091
I have both proxy and proxy_http mods enabled:
krzysiek:/etc/apache2$ a2enmod proxy
Module proxy already enabled
krzysiek:/etc/apache2$ a2enmod proxy_http
Module proxy already enabled
I am using Apache 2.4.7 and offical documentation states that:
In 2.4.7 and later, support for using a Unix Domain Socket is available by using a target which prepends unix:/path/lis.sock|
When I reload Apache I get error:
krzysiek:/etc/apache2$ sudo service apache2 restart
* Restarting web server apache2 [fail]
* The apache2 configtest failed.
AH00526: Syntax error on line 64 of /etc/apache2/sites-enabled/000-default.conf:
ProxyPass URL must be absolute!
I tried changing:
ProxyPass / unix:/var/(...)
To:
ProxyPass / unix:///var/(...)
Then Apache reloads correctly but forwarding DOES NOT work, error.log says:
[proxy:warn] [pid 22436] [client 10.0.4.19:47662] AH01144: No protocol handler was valid for the URL /. If you are using a DSO version of mod_proxy, make sure the proxy submodules are included in the configuration using LoadModule.
Could you explain me what I'm doing wrong? Or how do I forward traffic from port to unix socket on Apache correctly?
Might be a bit late 🙂, but the following apache config works for me:
ProxyRequests off
Define SOCKET_NAME /path/to/my.sock
ProxyPass / unix:${SOCKET_NAME}|uwsgi://%{HTTP_HOST}/
ProxyPassReverse / unix:${SOCKET_NAME}|uwsgi://%{HTTP_HOST}/
with modules proxy and proxy_uwsgi loaded.
Important do not place your socket in /tmp (I think systemd prevents the apache process to directly access it for security reasons).
Also, watch out for the file permissions.
I recently received an abuse report from Amazon (AWS) saying that my server was attempting to log in to forums and such. When I look at my error logs, I have lines and lines of:
[proxy:warn] [pid 2916:tid 1668] [client 82.117.234.134:6152] AH01144: No protocol handler was valid for the URL yandex.ru:443. If you are using a DSO version of mod_proxy, make sure the proxy submodules are included in the configuration using LoadModule.
[proxy:warn] [pid 2916:tid 1668] [client 120.132.54.62:58004] AH01144: No protocol handler was valid for the URL www.baidu.com:443. If you are using a DSO version of mod_proxy, make sure the proxy submodules are included in the configuration using LoadModule.
[proxy:warn] [pid 2916:tid 1672] [client 188.173.26.212:52049] AH01144: No protocol handler was valid for the URL l9bjkkhaycw6f8f4.soundcloud.com:443. If you are using a DSO version of mod_proxy, make sure the proxy submodules are included in the configuration using LoadModule.
[proxy:warn] [pid 2916:tid 1668] [client 104.199.176.143:56048] AH01144: No protocol handler was valid for the URL www.amazon.com:443. If you are using a DSO version of mod_proxy, make sure the proxy submodules are included in the configuration using LoadModule.
[proxy:warn] [pid 2916:tid 1744] [client 119.97.174.200:3700] AH01144: No protocol handler was valid for the URL zhifu.99.com:443. If you are using a DSO version of mod_proxy, make sure the proxy submodules are included in the configuration using LoadModule.
[proxy:warn] [pid 2916:tid 1712] [client 113.189.16.238:60122] AH01144: No protocol handler was valid for the URL s.youtube.com:443. If you are using a DSO version of mod_proxy, make sure the proxy submodules are included in the configuration using LoadModule.
My httpd-vhosts.conf is configured with:
<VirtualHost *:80>
ServerName demo.mysite.com
DocumentRoot "D:/sites/mysite/www/"
<Directory "D:/sites/mysite/www/">
AllowOverride All
Require all granted
</Directory>
ProxyPreserveHost On
ProxyPass "/data" "http://localhost:8080/data/"
ProxyPassReverse "/data" "http://localhost:8080/data/"
Header set Access-Control-Allow-Origin "*"
ErrorLog "logs/demo.mysite.com-error.log"
CustomLog "logs/demo.mysite.com-access.log" common
</VirtualHost>
Starting the server for even just a minute creates about 300+ lines of the above logs. This leads me to several questions:
Is my server possibly misconfigured or is it infected with something?
Where should I look to find out how it got like this?
UPDATE/EDIT:
It turns out that I had ProxyRequests On because a tutorial said that I have to have it on for Reverse Proxy to work. It's now turned off (ProxyRequests Off) and everything is fine. Thanks to Configuring mod_proxy for Apache to reject wrong domain requests
Make sure thatyou don't confuse Forward and Reverse Proxies. ProxyRequests On is for Forward Proxies. If you don't configure it properly after that, your server is an open proxy for the world. This is what is causing all of the logs is everyone using your (now) proxy server to access the internet.
For Reverse Proxies, make sure that you have ProxyRequests Off and then follow the rest of the configuration like adding ProxyPass and ProxyPassReverse.
Thanks to Configuring mod_proxy for Apache to reject wrong domain requests for pointing out that it is possible to turn your Apache server into an open proxy on accident.
I try to use Apache mod_proxy for icap protocol.
My configurations looks like:
<Location /RESPMOD>
ProxyPass icap://IP:1344/RESPMOD?policy=virus_only
ProxyPassReverse icap://IP:1344/RESPMOD?policy=virus_only
Order allow,deny
Allow from all
</Location>
The proxy module is built-in.
But than I get
[warn] proxy: No protocol handler was valid for the URL /RESPMOD. If you are using a DSO version of mod_proxy, make sure the proxy submodules are included in the configuration using LoadModule.
I didn't find proxy module for icap. Is there one (like for http protocol?) or should the configuration be different?
Unluckily, there is no such module.
I got an error 500 when trying to access to ws://localhost:8080/ via my Apache2 server. This server runs OpenSuse Leap 42.1 and Apache 2.4.16.
These Apache2 modules are enabled: mod_proxy, mod_proxy_http, mod_proxy_wstunnel.
When the request is called from the local network, everything works fine. URL example: http://<myhost-ip-address>/api/ws/<some-url>. It returns status 101 and the response: Upgrade: websocket. It's OK.
The same kind of request from external network fails. URL example: ws://www.mysite.com/api/ws/<some-url>. It returns error 500.
The Apache access log contains: GET /api/ws/<some-url> HTTP/1.1" 500 ...
The Apache error log contains: [proxy:warn] AH01144: No protocol handler was valid for the URL /api/ws/<some-url>. If you are using a DSO version of mod_proxy, make sure the proxy submodules are included in the configuration using LoadModule.
My httpd.conf:
<VirtualHost *:80>
ServerName mysite.com
ServerAlias mysite.com
# Redirection for ws protocol
ProxyPreserveHost On
ProxyVia full
ProxyRequests OffHere
RewriteEngine On
RewriteCond %{REQUEST_URI} ^/api/ws/(.*) [NC]
RewriteCond %{QUERY_STRING} transport=websocket [NC]
RewriteRule /(.*) ws://localhost:8080/$1 [P,L]
# Proxy pass
ProxyPass /api/ws/ ws://localhost:8080/api/ws/
ProxyPassReverse /api/ws/ ws://localhost:8080/api/ws/
# DocumentRoot
DocumentRoot /srv/www/vhosts/mysite.com
<Directory "/srv/www/vhosts/mysite.com">
Options Indexes SymLinksIfOwnerMatch
AllowOverride None
...
</Directory>
# URL as parameter
AllowEncodedSlashes NoDecode
I followed these previous StackOverflow answers (thank to that) :
websockets , node.js , socket-io , but with no luck.
Something must be wrong in my configuration. Any ideas ?
EDIT
As suggested by adona9, here are debug logs:
proxy_util.c(1784): AH00925: initializing worker ws://localhost:8080/api/ws/ shared
proxy_util.c(1826): AH00927: initializing worker ws://localhost:8080/api/ws/ local
...
mod_authz_core.c(809): AH01626: authorization result of Require user <user>: granted
mod_authz_core.c(809): AH01626: authorization result of <RequireAny>: granted
mod_charset_lite.c(219): AH01448: incomplete configuration: src unspecified, dst unspecified
mod_proxy.c(1159): AH01143: Running scheme ws handler (attempt 0)
mod_proxy_http.c(1944): AH01113: HTTP: declining URL ws://localhost:8080/api/ws/<some-url>
mod_proxy_wstunnel.c(341): AH02900: declining URL ws://localhost:8080/api/ws/<some-url> (not WebSocket)
[proxy:warn] H01144: No protocol handler was valid for the URL /api/ws/<some-url>. If you are using a DSO version of mod_proxy, make sure the proxy submodules are included in the configuration using LoadModule.
Any ideas ?
So I ended up spending a day and a half researching and reading up on deep apache2 configuration. This is how I was able to solve this problem:
Using both forensic_logs and DumpIO to find out my initial request headers on the apache2 end.
Log the request headers coming from websocket client.
VERIFY that both contain the upgrade header and connection type websocket in the request header. More than likely, these problems are a result of network filtering or removing of specific header files.
My problem was that I was using an AWS classic load balancer which DOES NOT support websocket connections.
While reading other forums, some companies' firewalls also remove specific header files from their connections, so it could also be that.
So more than likely if you've triple-checked to make sure you have the right modules installed, the more than likely error is network related.
If you have a network diagram, check each specific node and gateway and verify that the in and out request headers are the same.