Reverse proxy to QNAP does not work

Francis Daly francis at daoine.org
Wed Dec 30 17:24:31 UTC 2015


On Wed, Dec 16, 2015 at 03:38:51PM -0500, no.1 wrote:

Hi there,

> thanks for the details. I guess the trick is first to bypass a QNAP internal
> redirect to the NAS GUI (if possible or to integrate it on the first
> request). And second to to adapt the login request the right way. (btw: I
> try to avoid to change the qnap service, because of the regular QNAP
> firmware updates.)

You have a good reason not to change the qnap service itself to be below
/nas/; that's fine.

You're reluctant to use nas.home.example.com to access the qnap service
while using owncloud.home.example.com to access the owncloud service --
that's fine too. You may find that things do not work smoothly in that
case, but that's what happens.

> For the first topic the internal network traffic analysis from Firefox shows
> a lot of GET requests and some POST regarding the login:

I'm unsure what precisely you are doing to see these responses. It will
probably be easier for someone else to replicate what you are seeing,
if you can write down exactly what you do and exactly what you see.

For example, starting from a shell on the nginx server (the RasPi
machine), what responses do you get when you type each of

curl -v http://qnap:8080/
curl -v http://qnap:8080/redirect.html?count=0.xxxx
curl -v http://qnap:8080/cgi-bin/QTS.cgi?count=yyyyyy
curl -v http://qnap:8080/cgi-bin/
curl -v http://qnap:8080/photo

(using the urls that you mention)?

I suspect that some will be HTTP 301 or 302 redirects, and some will be
HTTP 200 responses with content which includes links to other things.

nginx's proxy_redirect can modify the http headers, but not the body
content -- so whether the application works easily through a reverse proxy
system depends on the application. The results from the above might hint
at whether the application works easily through a reverse proxy.

> So I tried it with http://qnap:8080/cgi-bin/login.html locally, which leads
> successfully to the login page http://qnap:8080/cgi-bin/. Changing the
> location part as suggested into:
>   location ^~ /nas/ {
>     proxy_pass http://qnap:8080/cgi-bin/;
>     proxy_set_header X-Real-IP $remote_addr;
>   }
> and trying the address https://example.com/nas/login.html results in a
> broken login page with a lot of 404 errors.

It is possible that

  location ^~ /nas/ {
    proxy_pass http://qnap:8080/;
  }

will be enough, where you would request /nas/cgi-bin/login.html; but it
all depends on your qnap application.

> Can anybody tell why it stays on external requests on content type "html"?
> Does it have to do something with Cache-Control?

One request gets one response; that response content may lead to more
requests for css and jpg and the like content.

If the initial response is 404, there is unlikely to be a follow-up
request.

Good luck with it,

	f
-- 
Francis Daly        francis at daoine.org



More information about the nginx mailing list