Hey Guys -
I recently upgraded my license from 7 to 8 and when doing so decided to perform a clean installation / setup on my Windows 10 x64 system. As with v7, I use a local installation of Apache for Windows to provide both an SSL layer and reverse proxy for a number of locally hosted services including CrushFTP. Since it provides SSL, I have it pointed to CrushFTP's HTTP listener.
Once I set 8 up and configured the listeners to the way I had them with v7, I tried visiting the proxied address, but am getting:
502 Proxy Error The proxy server received an invalid response from an upstream server. The proxy server could not handle the request GET /files. Reason: Error reading from remote server
Below is how I have things configured as well as what I've tried so far. Any suggestions would be appreciated!
CrushFTP HTTP Listener
- IP: lookup
- Port: 8383
- ReverseProxy Path: /files
- All other settings are default for HTTP
Visiting "http://127.0.0.1:8383/files" in Chrome works great, but testing "http://192.168.0.25:8383/files" (using static LAN IP) doesn't as after entering credentials it refreshes the page prompting for credentials again. Doesn't really matter I guess as long as the other works.
Apache Reverse Proxy Config
CrushFTP is one of about 20 local services I use RP for and all others are working well so if related it must be the config specific to CrushFTP. Below is it's config from httpd.conf.:
<Location /files> order deny,allow deny from all allow from all ProxyPass http://127.0.0.1:8383/files ProxyPassReverse http://127.0.0.1:8383/files </Location>
This is the same config I used for v7 with success. Other services use the same template and currently work as well. Although it shouldn't make any difference, I also tried "localhost" instead of 127.0.0.1. I did not try 192.168.0.25 since it failed testing as mentioned above.
Any suggestions? Thanks!
Couple more notes... :)
After posting, I found this article so tried the following:
- Changing the ReverseProxy Path for the HTTP listener from "/files" to "/files/" I saved and restarted the service, but still got the same error when trying to access via RP
- I tried the below code in httpd.conf, but after making the change; the Apache service wouldn't start so I reverted it to what I have above which worked for v7
<Location /files> order deny,allow deny from all allow from all ProxyPass /files/ http://127.0.0.1:8383/ ProxyPassReverse /files/ http://127.0.0.1:8383/ </Location>
Suggestions? Thanks again!
In CrushFTP prefs, http port, is the reverse proxy path set to be:
! indicates its a protocol change from https to http. And the path is how your proxying behind that.
Thank you for the reply!
I just tried that setting as shown below followed by restarting both the CrushFTP & Apache services, but unfortunately got the same error when trying to view the page via RP. Below are a couple of screenshots which may help explaining.
This is how I configured the HTTP listener's RP Path as suggested (public IP blurred out)
What Chrome displays when trying to browse to https://domain.com/files (Should be RP redirection of "http://127.0.0.1:8383/files" which still works after making the change to "!/files/")
Can you try just copying your CrushFTP v7 prefs.XML over to v8 to see if it works?
v7 and v8 use the same preference configuration in this area. It would be useful to know if the issue happens with both configs or not.
Also, it would help to see what is logged in the CrushFTP.log file when this fails.
I just tried visiting the reverse proxied path using Edge on the local PC - it worked! The old setting of "/files" worked as well. I then tried it from Chrome on another PC and it also worked. Must be something unique with the Chrome installation on the hosting PC although no changes have been made to it recently. There are no proxy settings configured (as there shouldn't be) and system malware scan was clean so go figure. Hopefully good to go from a CrushFTP perspective now.
Thanks for your help!
Try an incognito window on that chrome...if that works, then empty cache, reset chrome cookies/cache/etc.
I just got it working prior to seeing your post. I closed out of all Chrome instances then just ran CCleaner with options selected to clear Internet Cache, Cookies, Session, Saved Form Information, and Compact Databases. Browsing to RP address worked but it was a few seconds before I could type in fields. Once I could, I was golden and it now loads instantly whenever I visit the address.