Synology DSM – Reverse Proxy (Part 2)

On my previous post Synology virtual sites for FileStation and others we could see how to create new sub domains under the main DNS name for your Synology to access the DSM applications like FileStation, Notes Station, and so on.

The configuration that is done creates a new full virtual site, on other words, all URL paths under the new sub domain are proxied to the redirected application. By other words, supposing that points to FileStation, all URL paths below to that URL are redirected to the FileStation site (for example

The following configuration is a bit different and it’s purpose is to redirect a URL path from the main site to something else serving that path. For example, redirecting to a backend Node.js REST server. The main reason to this is to allow Synology to host a site that uses, for example JQuery, or AngularJS, to also host the REST API that needs to be on the same domain due to the browser CORS protection. CORS protection means that a loading page from a site can only request data, by REST for example, from the origin web site. For example, my pages on can call only REST services also on the same domain. It needs to be the same FQDN and PORT to the REST request be able to work. See more info at the Wikipedia page: Same-origin policy

And that’s because the above reason (CORS) that we need be able to proxy URL paths, and not full virtual sites, as the previous post as pointed out above.

To do this is quite simple, and the conditions are that the redirected path will be redirected from the main Synology user site.

So let’s redirect the path /api to a back end server:

Create a file named (for example) httpd-api-redirect.conf with the following content, replacing the backend_address and backend_port with the right information:

<Location /api>
  ProxyPass http://backend_address:backend_port/api

Save this file at /etc/httpd/sites-enabled-user, and stop and restart the Apache server:

(Edit: In DSM 6.0 the path is /usr/local/etc/httpd/sites-enabled  )

To stop the Web Station: /sbin/initctl stop httpd-user
To start the Web Station:  /sbin/initctl start httpd-user

After that accessing should work as usual, but should be redirected to the backend server.

And that’s it, we can now host JQuery and/or Angular sites that use REST services hosted on the Synology Apache server.

There also some caveats regarding this configuration, if serving another site, not a REST api, like the full/relative paths issue with the proxied site, and also, regarding REST, the use of the Accept-origin header. But for the simplest purpose of hosting the site and the REST api under the same domain name, this works fine.

20 thoughts on “Synology DSM – Reverse Proxy (Part 2)

  1. Thanks for replying.
    Proxy modules are loading.
    My problem is that probably nginx server is intercepting the requests, and I get a 403 or 404 code.

    1. The “backend_address:backend_port/api ” means something like “” or the FQDN?
    2. I’m now trying to do the same thing but with fiddling with nginx configuration, as I suspect this is the problem.

    1. Hummm, I also have nginx at the front-end doing the reverse proxy stuff that is standard now on DSM 6.0, and also this and it works fine so probably is not that. Nginx will redirect full sites while the above Apache configuration only redirect paths.

      The backend address and port is the server address and port where we want to redirect the URL path to, not the Synology address and port.

      So for example if I have a domain named it shows my DSM web server home page, but is redirected to the backend server. I do not change the base URL or add new port. The rule only intercepts and redirects /backend to backend_address:backend_port/api to somewhere else.

      The above configuration will only work for redirecting url paths, not full sites.

  2. I’m sorry. I cannot understand it.

    I’m also trying to redirect only a url path ( ) to the backend path ( ).
    My reason is the same as yours : to overcome the Same Origin Policy.

    To explain my situation :
    I’m using the Synology Filestation API ( through an PHP application ) to access files directly on the DS .
    Till now I’ve managed with HTTP Requests to the Synology REST API, to Authenticate, List Share Folders, etc.
    But when I try to make an AJAX call through query (or plain JS) to the DS, in order to Download a file,I get back the
    ‘Origin “” is not allowed by Access-Control-Allow-Origin
    The same file is downloaded correctly if I use a direct HTTP GET request through PHP.

    I also tried to set some headers to Allow Cross Origin in httpd conf files ( and .htaccess file ) but with no success.

    Do you have something else to suggest?

    1. So with a direct request to and it works? But through a web service caller it fails with the CORS error?

  3. No, this is not the case.
    Without any modification to any file, the AJAX call fails due different ports (5000 vs 80).
    My PHP application lives also in and is served through 80, BUT the Synology REST API should be called through port 5000 !
    This is the problem I’m trying to solve and google presented your page.

    Trying to follow your guide :
    After adding the following to /usr/local/etc/httpd/sites-enabled/api-redirect.conf


    and restarting httpd via
    httpd -k restart (because /sbin/initctl stop httpd-user does not work with DSM 6.0)
    it does not work : http:/ brings back 403.

    Sorry for asking too much, but I’m searching for a couple of days for a solution, without any success.

    1. Ok, I was able to make it work, so:

      Not sure if your following my example, that is a bit generic 🙂 As it seems for DSM 6.0 the correct URL to access the API would be http:server_ip:5000//webapi/entry.cgi

      So the proxy pass command should be Proxypass http://internal_syno_ip:5000/webapi/entry.cgi

      1) So you must create a file named, for example synoapi-site.conf at the following directory: /usr/local/etc/httpd/sites-enabled/

      2) On that file, you put the Location tag and the Proxypass command as above

      3) Save the file

      4) Restart the Apache Server with the command: synoservice –reload pkgctl-WebStation

      5) Access the Syno Web site:

      6) Acess the redirected URL at:

      If it fails check the logs at /var/log/httpd, mainly the user-error.log file

      If it is still failing due to missing CORS header, you might need a proxy for the API like this:

      Tell me how it goes 🙂

  4. It worked!
    Thank you!

    But afterwards I stumbled on another issue that I haven’t considered :
    AJAX requests cannot “download” files..

    So I didn’t use AJAX requests after all, just a“url”)

    Thanks anyway. I learned much from this.

  5. Looks like the latest synology update killed this capability.

    Now having such a .conf file in /usr/local/etc/httpd/sites-enabled/, the apache package cannot start emitting :

    service [pkgctl-Apache2.2] restart failed, synoerr=[0x2000]

    Removing the .conf file, apache starts again.

    I haven’t changed anything else.
    The contents are :


    It used to work flawlessly before the update..

    Any thoughts?

    1. OK. I managed to started it again by prepending the following as you are suggesting :

      ! IfModule !proxy_module
      LoadModule proxy_module modules/
      LoadModule proxy_connect_module modules/
      LoadModule proxy_http_module modules/

      apache did not load mod_proxy by default.
      From now on I’ll be more careful with synology updates.

      1. The rewrite rule should be something like:

          location / 

        Where is your real address. Also make sure that the location tags are between the less and greater signal, not sure if the they get commented out on this reply.

  6. Would this work for accessing Home Assistant? I have tried your reverse proxy 1 (thank you) and managed to get to the front end home page of my instance but the page will not load fully and I cannot login. The instance runs on port 8123 so I have done a reverse proxy that routes to http://ipaddressofmyPi3:8123. While this works, the page does not fully load and if I set a HTTP API password, I cannot login remotely. I’ve tested the reverse proxy by doing the same thing but routing it to my internal instance of ha-bridge and the webpage loads and allows me to login.

    Could the CORS sub-section of the HTTP section to amended to allow the proxy to work with the Home Assistant API or would your method work?

    1. Hi, first of all when doing the request, press F12 in your browser and check if there is a request failing either due to the reverse proxy or due to CORS.

      The main problem might be that the reversed proxied site sends to the client invalid/internal URL’s instead of the outside, reverse proxy, urls, which can lead to a lot of issues. The only real way to check it is to debug it with the browser Network request tab. Hope this helps.

Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Google photo

You are commenting using your Google account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s

This site uses Akismet to reduce spam. Learn how your comment data is processed.