{"id":6905,"date":"2026-02-24T11:31:23","date_gmt":"2026-02-24T06:01:23","guid":{"rendered":"https:\/\/toolswift.com\/blog\/?p=6905"},"modified":"2026-02-24T11:31:23","modified_gmt":"2026-02-24T06:01:23","slug":"how-to-build-a-self-hosted-reverse-proxy-with-valid-ssl-for-local-only-access-on-synology-nas","status":"publish","type":"post","link":"https:\/\/toolswift.com\/blog\/how-to-build-a-self-hosted-reverse-proxy-with-valid-ssl-for-local-only-access-on-synology-nas\/","title":{"rendered":"How to Build a Self-Hosted Reverse Proxy with Valid SSL for Local-Only Access on Synology NAS"},"content":{"rendered":"

Running multiple self-hosted apps on a Synology NAS is easy\u2014until you want them to feel \u201cproduction clean\u201d: one HTTPS URL per app (no ports), trusted certificates (no browser warnings), and LAN-only access (nothing exposed to the public internet).<\/p>\n

This guide shows two proven ways to do it:<\/p>\n

Option A (Best for \u201cpublicly trusted\u201d SSL):<\/strong> Use a real domain + Let\u2019s Encrypt DNS-01 challenge so certificates are valid even if your NAS is never reachable from the internet. (Recommended for most people.)<\/p>\n

Option B (Best for purely internal names):<\/strong> Use a private CA (step-ca or Caddy\u2019s internal CA) for internal-only domains like *.lan<\/strong> or *.home<\/strong>.<\/p>\n

You\u2019ll also lock access down so the reverse proxy only works inside your home network.<\/p>\n

Target Outcome<\/h2>\n

You\u2019ll end up with URLs like:<\/p>\n

    \n
  • https:\/\/vaultwarden.home.example.com<\/strong><\/li>\n
  • https:\/\/photos.home.example.com<\/strong><\/li>\n
  • https:\/\/ha.home.example.com<\/strong><\/li>\n<\/ul>\n

    All of them:<\/p>\n

      \n
    • terminate TLS at the NAS reverse proxy<\/li>\n
    • show a valid certificate<\/li>\n
    • route to internal services (Docker containers, NAS packages, other LAN servers)<\/li>\n
    • are not reachable from the internet<\/li>\n<\/ul>\n

      What You Need<\/h2>\n

      Hardware \/ software<\/h3>\n
        \n
      • Synology NAS on DSM 7.x<\/li>\n
      • Your apps running on the NAS (Docker\/Container Manager or Synology packages) or on other LAN hosts<\/li>\n<\/ul>\n

        Network & DNS<\/h3>\n

        A way to resolve your chosen hostnames inside your LAN:<\/p>\n

          \n
        • your router\u2019s DNS, or<\/li>\n
        • Pi-hole \/ Technitium \/ AdGuard Home, or<\/li>\n
        • Synology DNS Server package<\/li>\n<\/ul>\n

          For Option A (publicly trusted SSL)<\/h3>\n
            \n
          • A real domain you control (e.g., example.com)<\/li>\n
          • DNS provider that supports API access (Cloudflare, Route53, etc.) for automated TXT records<\/li>\n<\/ul>\n

            Core Design: Reverse Proxy + Split DNS + Firewall<\/h2>\n

            1) Reverse proxy on Synology<\/h3>\n

            DSM includes a reverse proxy UI where you map:<\/p>\n

            Source (public-facing in LAN): https:\/\/app.example.com:443<\/strong>
            \n\u2192 Destination (your real service): http:\/\/127.0.0.1:8080<\/strong> (or another LAN IP\/port)<\/p>\n

            Synology documents this under Control Panel \u2192 Application Portal \u2192 Reverse Proxy<\/strong> (DSM 7).<\/p>\n

            2) Local DNS<\/h3>\n

            Your LAN clients must resolve app.example.com<\/strong> to your NAS LAN IP (e.g., 192.168.1.10<\/strong>). That\u2019s the key to \u201clocal-only\u201d without exposing anything publicly.<\/p>\n

            3) Local-only enforcement<\/h3>\n

            You ensure no WAN access by:<\/p>\n

              \n
            • not forwarding ports 80\/443 on your router<\/li>\n
            • adding Synology firewall rules to only allow LAN subnets to connect (details below)<\/li>\n<\/ul>\n

              Option A (Recommended): Valid Public SSL with Let\u2019s Encrypt DNS-01 (No Public Exposure)<\/h2>\n

              Why DNS-01 is the trick<\/h3>\n

              Let\u2019s Encrypt normally validates using HTTP (requires your server to be reachable). But DNS-01 proves ownership via a TXT record in DNS, so the server does not need to be internet-accessible.<\/p>\n

              Synology\u2019s built-in certificate flow has limitations around DNS challenge support (varies by setup\/provider), so a common reliable approach is using acme.sh<\/strong> and then deploying the cert into DSM.<\/p>\n

              Step A.1 \u2014 Pick a naming scheme<\/h3>\n

              A clean pattern is:<\/p>\n

              *.home.example.com<\/strong> for all internal apps<\/p>\n

              Example:<\/p>\n

                \n
              • vaultwarden.home.example.com<\/li>\n
              • ha.home.example.com<\/li>\n
              • nas.home.example.com<\/li>\n<\/ul>\n

                This makes wildcard certs very convenient.<\/p>\n

                Step A.2 \u2014 Configure DNS (public + local)<\/h3>\n

                Public DNS (at your domain registrar\/DNS provider)<\/h4>\n

                You only need DNS access for the TXT records (ACME challenge). You can choose one of these:<\/p>\n

                Approach 1 (Simple):<\/strong>
                \nSet A records for *.home.example.com<\/strong> to your NAS private IP (e.g., 192.168.1.10<\/strong>). This works for most home setups, but you are publishing a private IP in public DNS (not dangerous by itself, just messy).<\/p>\n

                Approach 2 (Cleaner): Split DNS<\/strong><\/p>\n

                Public DNS: *.home.example.com<\/strong> can point anywhere (or not exist at all; DNS-01 can still work with wildcard issuance depending on provider\/tooling).<\/p>\n

                Local DNS: create A records so your LAN resolves *.home.example.com \u2192 192.168.1.10<\/strong>.<\/p>\n

                Most people prefer split DNS so internal services don\u2019t \u201cdepend\u201d on public resolution.<\/p>\n

                Step A.3 \u2014 Issue a wildcard certificate with acme.sh (DNS API)<\/h3>\n

                Where to run acme.sh<\/h4>\n
                  \n
                • In a Docker container on the NAS, or<\/li>\n
                • via Synology SSH + Task Scheduler (Docker is usually cleaner)<\/li>\n<\/ul>\n

                  acme.sh provides a Synology DSM deploy hook (synology_dsm.sh<\/strong>) specifically to install certs into DSM automatically.<\/p>\n

                  Example (conceptual) issuance flow<\/h4>\n

                  You\u2019ll use your DNS provider\u2019s acme.sh DNS plugin (example: Cloudflare plugin name is dns_cf<\/strong>, other providers differ).<\/p>\n

                  Typical commands look like:<\/p>\n

                  Issue:<\/p>\n

                  acme.sh --issue --dns <dns_plugin> -d \"*.home.example.com\" -d \"home.example.com\"<\/code><\/pre>\n
                  Deploy into DSM:<\/p>\n
                  acme.sh --deploy --deploy-hook synology_dsm -d \"*.home.example.com\"<\/code><\/pre>\n
                  The DSM deploy hook is a standard approach used in real Synology DNS-challenge setups.<\/p>\n
                  Important:<\/strong> the deploy hook needs DSM credentials\/host details (set as environment variables per the hook documentation\/script).<\/p>\n
                  Step A.4 \u2014 Make renewal automatic<\/h3>\n
                  Let\u2019s Encrypt certs are short-lived (90 days). Your goal is zero manual renewals.<\/p>\n
                  Common patterns:<\/p>\n
                    \n
                  • Run acme.sh container with a cron-like schedule<\/li>\n
                  • Or use Synology Task Scheduler to run the renew\/deploy command daily<\/li>\n<\/ul>\n
                    acme.sh is designed to renew automatically and redeploy when needed.<\/p>\n
                    Step A.5 \u2014 Assign the certificate in DSM<\/h3>\n
                    Once the cert is installed in DSM:<\/p>\n
                      \n
                    • Go to Control Panel \u2192 Security \u2192 Certificate<\/strong><\/li>\n
                    • Ensure the wildcard cert is set as default, and\/or assigned to the services (Reverse Proxy \/ DSM \/ apps)<\/li>\n<\/ul>\n
                      (Some deployments apply it automatically; if not, you assign it in DSM.)<\/p>\n
                      Configure DSM Reverse Proxy Rules (Works for both Option A and B)<\/h2>\n
                      Step RP.1 \u2014 Create a reverse proxy entry<\/h3>\n
                      DSM 7 path (varies slightly by DSM build, but typically):<\/p>\n
                      Control Panel \u2192 Application Portal \u2192 Reverse Proxy \u2192 Create<\/strong><\/p>\n
                      You\u2019ll set:<\/p>\n
                      Source<\/strong><\/p>\n
                        \n
                      • Protocol: HTTPS<\/li>\n
                      • Hostname: vaultwarden.home.example.com<\/li>\n
                      • Port: 443<\/li>\n<\/ul>\n
                        Destination<\/strong><\/p>\n
                          \n
                        • Protocol: HTTP (or HTTPS if your backend uses it)<\/li>\n
                        • Hostname: 127.0.0.1 (or container host \/ LAN IP)<\/li>\n
                        • Port: 8080 (example)<\/li>\n<\/ul>\n
                          Repeat per app.<\/p>\n
                          Tip:<\/strong> Keep backends on HTTP internally unless you truly need end-to-end TLS. The reverse proxy is your TLS boundary for LAN.<\/p>\n
                          Step RP.2 \u2014 (Optional but recommended) Add security headers<\/h3>\n
                          In Synology reverse proxy \u201cCustom Header\u201d settings (if available), common additions:<\/p>\n
                            \n
                          • HSTS (only if you\u2019re sure you want HTTPS always)<\/li>\n
                          • X-Forwarded-Proto, X-Forwarded-For (often automatic)<\/li>\n<\/ul>\n
                            Keep it minimal unless you know the app requirements.<\/p>\n
                            Lock It to Local-Only Access<\/h2>\n
                            Step L.1 \u2014 Do NOT port-forward 80\/443 from your router<\/h3>\n
                            This is the biggest lever. If WAN traffic can\u2019t reach your NAS, your proxy stays local.<\/p>\n
                            If you previously had port forwards, remove them.<\/p>\n
                            Step L.2 \u2014 Use Synology Firewall to allow LAN subnets only<\/h3>\n
                            Enable DSM firewall and create rules like:<\/p>\n
                              \n
                            • Allow your LAN subnet (example: 192.168.1.0\/24<\/strong>) to ports 443 (and 80 only if you need HTTP\u2192HTTPS redirects)<\/li>\n
                            • Deny everything else (catch-all)<\/li>\n<\/ul>\n
                              Rule ordering matters in DSM firewall.<\/p>\n
                              Note:<\/strong> If you find reverse proxy behaves unexpectedly with firewall rules, you\u2019re not alone\u2014there are community reports around reverse proxy and firewall interactions, so test from both LAN and a non-LAN client (like phone on cellular).<\/p>\n
                              Step L.3 \u2014 Ensure LAN DNS is authoritative for your internal hostnames<\/h3>\n
                              Make sure your devices actually use your LAN DNS (router DNS, Pi-hole, etc.). Otherwise, they may query public DNS and not reach your NAS correctly.<\/p>\n
                              Option B: Valid HTTPS for Internal-Only Domains Using a Private CA (step-ca or Caddy Internal CA)<\/h2>\n
                              If you want names like:<\/p>\n
                                \n
                              • https:\/\/vaultwarden.lan<\/strong><\/li>\n
                              • https:\/\/ha.home.arpa<\/strong><\/li>\n<\/ul>\n
                                or you simply don\u2019t want to use a public domain at all, you need a private CA.<\/p>\n
                                Two solid approaches<\/h3>\n
                                B.1) step-ca (Private ACME CA)<\/h4>\n
                                  \n
                                • step-ca runs as your internal Certificate Authority<\/li>\n
                                • ACME clients can request\/renew certs automatically (similar workflow to Let\u2019s Encrypt, but private)<\/li>\n<\/ul>\n
                                  Pros:<\/strong><\/p>\n
                                    \n
                                  • Fully internal<\/li>\n
                                  • Automated issuance\/renewal using ACME<\/li>\n<\/ul>\n
                                    Cons:<\/strong><\/p>\n
                                      \n
                                    • You must distribute and trust your root CA on your devices (once per device\/OS)<\/li>\n<\/ul>\n
                                      B.2) Caddy\u2019s internal CA mode<\/h4>\n
                                      Caddy can issue and manage internal certificates (not publicly trusted) and can do internal PKI flows.<\/p>\n
                                      Pros:<\/strong><\/p>\n
                                        \n
                                      • Very simple if you\u2019re already using Caddy<\/li>\n
                                      • Automatic renewals<\/li>\n<\/ul>\n
                                        Cons:<\/strong><\/p>\n
                                          \n
                                        • Same trust distribution requirement (install CA root on clients)<\/li>\n<\/ul>\n
                                          Practical note:<\/strong> If your goal is \u201cno warnings on every device without installing anything,\u201d Option A (public domain + DNS-01) is usually the winner.<\/p>\n
                                          Troubleshooting Checklist<\/h2>\n
                                          Certificate issuance fails<\/h3>\n
                                            \n
                                          • DNS API credentials wrong or missing<\/li>\n
                                          • TXT record not propagating quickly enough<\/li>\n
                                          • Using an internal-only TLD (public CAs won\u2019t issue for .lan, .internal, etc.) \u2014 you\u2019ll see errors like \u201cdoes not qualify for a public certificate\u201d in some setups<\/li>\n<\/ul>\n
                                            Reverse proxy works by IP:port but not by hostname<\/h3>\n
                                              \n
                                            • LAN DNS doesn\u2019t resolve app.home.example.com to the NAS LAN IP<\/li>\n
                                            • Client is using a different DNS server than you think<\/li>\n<\/ul>\n
                                              It\u2019s accessible from the internet (you don\u2019t want that)<\/h3>\n
                                                \n
                                              • Router port forward is still enabled<\/li>\n
                                              • DSM firewall rule order is wrong (allow rules must be above deny-all)<\/li>\n<\/ul>\n
                                                Recommended \u201cBest Practice\u201d Setup Summary (Most Homes)<\/h2>\n
                                                  \n
                                                • Use *.home.example.com<\/strong><\/li>\n
                                                • Local DNS resolves those names to NAS LAN IP<\/li>\n
                                                • Issue wildcard Let\u2019s Encrypt cert via DNS-01 using acme.sh<\/strong><\/li>\n
                                                • Deploy cert into DSM with synology_dsm<\/strong> deploy hook<\/li>\n
                                                • DSM Reverse Proxy maps each hostname \u2192 internal service<\/li>\n
                                                • No router port forwards<\/li>\n
                                                • DSM firewall: allow LAN \u2192 443, deny everything else<\/li>\n<\/ul>\n","protected":false},"excerpt":{"rendered":"
                                                  Running multiple self-hosted apps on a Synology NAS is easy\u2014until you want them to feel \u201cproduction clean\u201d: one HTTPS URL per app (no ports),…<\/p>\n","protected":false},"author":1,"featured_media":6906,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[7],"tags":[],"class_list":["post-6905","post","type-post","status-publish","format-standard","has-post-thumbnail","hentry","category-how-to"],"_links":{"self":[{"href":"https:\/\/toolswift.com\/blog\/wp-json\/wp\/v2\/posts\/6905","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/toolswift.com\/blog\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/toolswift.com\/blog\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/toolswift.com\/blog\/wp-json\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/toolswift.com\/blog\/wp-json\/wp\/v2\/comments?post=6905"}],"version-history":[{"count":3,"href":"https:\/\/toolswift.com\/blog\/wp-json\/wp\/v2\/posts\/6905\/revisions"}],"predecessor-version":[{"id":6909,"href":"https:\/\/toolswift.com\/blog\/wp-json\/wp\/v2\/posts\/6905\/revisions\/6909"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/toolswift.com\/blog\/wp-json\/wp\/v2\/media\/6906"}],"wp:attachment":[{"href":"https:\/\/toolswift.com\/blog\/wp-json\/wp\/v2\/media?parent=6905"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/toolswift.com\/blog\/wp-json\/wp\/v2\/categories?post=6905"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/toolswift.com\/blog\/wp-json\/wp\/v2\/tags?post=6905"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}