--- title: "Nginx server" slug: "nginx-server" description: "Nginx is an open-source web server.To know more, visit the To set up a sub folder/subdirectory Add the following location blocks in your Nginx configuration file /etc/nginx/default." tags: ["Custom domain", "Sub directory hosting"] updated: 2026-08-21T09:49:27Z published: 2026-08-21T09:49:27Z canonical: "docs.document360.com/nginx-server" --- > ## Documentation Index > Fetch the complete documentation index at: https://docs.document360.com/llms.txt > Use this file to discover all available pages before exploring further. # Nginx server Hosting your Document360 knowledge base in a subfolder on Nginx, such as `example.com/docs`, requires configuring proxy and rewrite rules on your server. This article covers enabling the required location blocks, routing UI and API paths, generating sitemaps, and handling URL redirection to avoid duplicate content in search engines. To learn more about Nginx itself, see the [Nginx documentation](https://nginx.org/en/docs/). --- ## Before you begin - Subfolder hosting works only when both the **Subfolder path** (for example, `/docs` or `/help`) and the **Site API path** (for example, `/api` or `/docs-api`) are defined in Document360. After setting these values, configure corresponding `location` blocks in Nginx to proxy both UI and API traffic. - Replace the example domain throughout this article with your own Document360-provided domain or custom domain. For example, `example.document360.io` represents your domain, and `example.document360.io/docs` represents your subfolder path. --- ## How to configure a subfolder path in Nginx 1. Add the following location block to your Nginx configuration file (`/etc/nginx/default`): ``` location /docs { proxy_pass https://example.document360.io/docs; proxy_set_header Host example.document360.io; proxy_set_header X-Real-IP $remote_addr; proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for; proxy_set_header X-Forwarded-Proto $scheme; proxy_set_header "requested-by" "proxy"; proxy_ssl_server_name on; proxy_set_header Cookie "kb_version=2; $http_cookie"; } ``` NOTE The `Cookie` header ensures that Markdown (`.md`) article URLs and `llms.txt` — which AI crawlers use to read your content — resolve correctly under your subfolder path. Without it, these requests return a 404 even though the HTML pages work. The `$http_cookie` variable preserves the reader's existing cookies. Add this header to every location block that proxies knowledge base traffic, including the Site API path and workspace blocks. 1. Restart the Nginx web server. On Linux, use: ``` sudo systemctl restart nginx ``` --- ## How to use a custom subfolder path You can host your knowledge base on a path other than `/docs`, such as `/help` or `/support`. When setting up a custom path, also add the languages associated with each workspace, then restart the server. The example below maps the Document360 provided domain `example.document360.io`, workspace `/v1/`, subfolder path `/help/`, and Hebrew language code `/he` — replace these with your own values. ``` location /help { proxy_pass https://example.document360.io/docs; proxy_set_header Host example.document360.io; proxy_set_header X-Real-IP $remote_addr; proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for; proxy_set_header X-Forwarded-Proto $scheme; proxy_set_header "requested-by" "proxy"; proxy_ssl_server_name on; proxy_set_header Cookie "kb_version=2; $http_cookie"; sub_filter "v1/docs/" "v1/help/"; sub_filter "docs/he/" "/help/he"; sub_filter "/docs/" "/help/"; sub_filter_once off; } ``` ### Removing the workspace slug from internal links To remove workspace slugs from internal links at the Nginx reverse proxy level, use a `sub_filter` rule: ``` sub_filter "/Version_slug/docs/" "/help/"; ``` This rewrites workspace-specific paths before they're served to readers. Use this approach only if your site structure requires workspace-agnostic URLs. --- ## Why `proxy_set_header Accept-Encoding ""` is required When hosting in a custom subfolder, Nginx commonly uses `sub_filter` to rewrite internal URLs such as `/docs` to `/help`. By default, the upstream server (Document360) may return gzip-compressed HTML, and Nginx can't apply `sub_filter` rules to compressed responses. This causes internal links to go unrewritten, home page widgets to keep pointing to `/docs`, and category cards or navigation routes to break. To fix this, disable compression from the upstream server: ``` proxy_set_header Accept-Encoding ""; ``` This forces Document360 to return uncompressed HTML, allows `sub_filter` rules to execute correctly, and ensures paths such as `/docs/en/` are rewritten to `/help/en/`. This setting is required whenever `sub_filter` is used. --- ## How to configure the Site API path If you're hosting your knowledge base in a subfolder, you must also define a **Site API path** and add a corresponding `location` block in Nginx, to ensure API requests route correctly and prevent redirect loops or broken API calls. The example below uses `/api` as the Site API path: ``` location /api { proxy_pass https://example.document360.io/api; proxy_set_header Host example.document360.io; proxy_set_header X-Real-IP $remote_addr; proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for; proxy_set_header X-Forwarded-Proto $scheme; proxy_set_header "requested-by" "proxy"; proxy_ssl_server_name on; proxy_set_header Cookie "kb_version=2; $http_cookie"; proxy_set_header Accept-Encoding ""; sub_filter_types *; sub_filter "v1/docs/" "v1/help/"; sub_filter "docs/he/" "/help/he"; sub_filter "/docs/" "/help/"; sub_filter_once off; } ``` NOTE Replace `/api` and `/docs-api` in the example with the exact values configured under **Site API path** in the Document360 portal. The API path configured in the portal and the Nginx location block must match exactly. Once you've added both location blocks, restart Nginx: ``` sudo systemctl restart nginx ``` Use `sub_filter_types *;` only when rewriting HTML or API responses that may return non-HTML content — avoid it unless URL rewriting is actually required. ### When to use sub_filter in the API location block Adding `sub_filter` rules to the API location block isn't always necessary. Use it only when your UI path is rewritten (for example, `/docs` → `/help`) or when API responses contain embedded `/docs` paths that need rewriting. If your project continues to use `/docs` as the UI path, don't add `sub_filter` rules to the API block. NOTE If your domain already uses `/api` for another application, update the Site API path in the Document360 portal to a different value, such as `/docs-api`, and use the same path in your Nginx configuration. --- ## How to enable the workspaces dropdown To enable workspace dropdown navigation when hosting in a custom subdirectory, add a code block for each workspace in your project. The example below covers two workspaces, `v1` and `v2`, with Document360 domain `example.document360.io`, subfolder path `/help/`, and Hebrew language `/he` — replace these with your own values. ``` location /v2/help { proxy_pass https://example.document360.io/v2/docs; proxy_set_header Host example.document360.io; proxy_set_header X-Real-IP $remote_addr; proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for; proxy_set_header X-Forwarded-Proto $scheme; proxy_set_header "requested-by" "proxy"; proxy_ssl_server_name on; proxy_set_header Cookie "kb_version=2; $http_cookie"; sub_filter "v2/docs/" "v2/help/"; sub_filter "docs/he/" "/help/he"; sub_filter "/docs/" "/help/"; sub_filter_once off; } location /v1/help { proxy_pass https://example.document360.io/v1/docs; proxy_set_header Host example.document360.io; proxy_set_header X-Real-IP $remote_addr; proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for; proxy_set_header X-Forwarded-Proto $scheme; proxy_set_header "requested-by" "proxy"; proxy_ssl_server_name on; proxy_set_header Cookie "kb_version=2; $http_cookie"; sub_filter "v1/docs/" "v1/help/"; sub_filter "docs/he/" "/help/he"; sub_filter "/docs/" "/help/"; sub_filter_once off; } location = /v2/docs { return 301 /v2/help; } location = /v1/docs { return 301 /v1/help; } ``` NOTE To let readers navigate between public workspaces from the dropdown, add a location block for each available workspace. Restart Nginx once configured: ``` sudo systemctl restart nginx ``` The default home page for a knowledge base site appears at the root directory, for example `example.document360.io`. If your project has a workspace- and language-specific home page, the slug after the root directory follows the format `/<workspace_name>/<language_code>`, for example `example.document360.io/v2/he`. --- ## How to set up sitemap generation The sitemap prefix stays the same except for the language code (en, fr, de, and so on). ``` location /sitemap.xml.en { proxy_pass https://example.document360.io/sitemap.xml.en; proxy_set_header Host example.document360.io; proxy_set_header X-Real-IP $remote_addr; proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for; proxy_set_header X-Forwarded-Proto $scheme; proxy_set_header "requested-by" "proxy"; proxy_ssl_server_name on; proxy_set_header Accept-Encoding ""; sub_filter_types text/xml; sub_filter "https://www.example.document360.io/docs/" "https://www.example.document360.io/help/"; sub_filter_once off; } ``` --- ## How to set the canonical URL When hosting your knowledge base in a subfolder, configure a canonical URL so search engines index your custom domain and subfolder path instead of the default `*.document360.io` domain. This prevents duplicate indexing and improves SEO performance. 1. Navigate to **Settings** () > **Knowledge base site** > **Custom domain** > **Subfolder hosting**. 2. Enter the full subfolder URL, for example `https://example.com/help`. 3. Click **Save**. Once configured, search engines treat the subfolder URL as the primary source for indexing. --- ## What happens next Once Nginx is configured, your knowledge base site is live on your custom subfolder. The existing Document360 URL continues to serve requests as well - for example, both `example.document360.io` and `example.com/docs` will point to your knowledge base site. This causes duplicate content in search engines. To prevent this, enable the **Restrict subdomain access** toggle under **Settings** () > **Knowledge base site** > **Custom domain** > **Subfolder hosting**. Make sure a canonical domain is configured first - once enabled, your Document360 subdomain automatically redirects to your canonical domain. --- ## Helpful links - [NGINX Docs: Configuring NGINX and NGINX Plus as a Web Server](https://docs.nginx.com/nginx/admin-guide/web-server/web-server/) - [DigitalOcean: Understanding Nginx Server and Location Block Selection Algorithms](https://www.digitalocean.com/community/tutorials/understanding-nginx-server-and-location-block-selection-algorithms) --- ## Best practices - Always add `proxy_set_header Accept-Encoding "";` to any location block using `sub_filter`, or your rewrite rules won't apply to compressed responses. - Add `proxy_set_header Cookie "kb_version=2; $http_cookie";` to every location block that proxies knowledge base traffic, so Markdown (`.md`) and `llms.txt` requests resolve under your subfolder path instead of returning a 404. - Keep the Site API path identical between the Document360 portal and your Nginx configuration — a mismatch causes broken API calls. - Add `sub_filter` rules to the API location block only when your UI path is rewritten or API responses contain embedded `/docs` paths. - Configure a canonical URL before enabling Restrict subdomain access, to avoid redirect issues during setup. --- ## FAQ **Why is my site's home page not available?** After designing your project's home page in the site builder, make sure you publish it. Confirm the home page is live and accessible to the intended audience. **Why are my home page widgets and category links redirecting to /docs instead of /help?** This happens when Nginx sub_filter rewriting isn't applied, usually because the upstream server returns gzip-compressed HTML, which sub_filter can't process. As a result, /docs paths inside the HTML aren't rewritten. Fix this by adding proxy_set_header Accept-Encoding ""; to the relevant location block, which forces uncompressed HTML, lets sub_filter rules execute, and ensures internal links route to the correct subfolder path. **Why do my article .md URLs return a 404 when the HTML pages work?** This happens when the knowledge base site version isn't passed through the proxy, so requests for Markdown (.md) files and llms.txt redirect repeatedly and fail. It is most common on sites using a custom subfolder path such as /articles or /help. Add proxy_set_header Cookie "kb_version=2; $http_cookie"; to your knowledge base location blocks and restart Nginx. To confirm the fix, open https://example.com/help/article-slug.md and https://example.com/help/llms.txt in a browser — both should return content rather than a 404. ## Related - [Apache HTTP server](/apache-http-server.md) - [Subfolder hosting](/subfolder-hosting.md) - [ASP.NET Core server](/aspnet-core-server.md)