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.

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;
}

2. 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;

    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 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;
}

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.

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;

    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;

    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;
}

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
• DigitalOcean: 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.
• 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