iTechGuides is reader-supported. When you buy through links on our site, we may earn an affiliate commission. As an Amazon Associate I earn from qualifying purchases. Learn more
To disable generated directory listings in Nginx on Ubuntu 24.04, add autoindex off; to the active http, server, or (preferably) affected location block, then reload Nginx with sudo systemctl reload nginx. Test a directory URL ending in / that has no index file. Nginx documents off as the default, so an existing listing normally means that another active configuration has enabled autoindex on;.
This changes only Nginx’s generated listing response. It does not delete files, create an index page, or necessarily force a 404; the final response still depends on the matching configuration and whether an index file exists.
Disable the listing in four steps
- Identify the server block handling the hostname and path. On Ubuntu’s documented single-site setup, start with
/etc/nginx/sites-enabled/default. For named sites, inspect the enabled links in/etc/nginx/sites-enabled/and edit the corresponding file in/etc/nginx/sites-available/. - Place the directive in the narrowest matching scope. In the relevant block, add
autoindex off;. A typical location looks like this:server { # existing listen, server_name, root, and other directives location / { autoindex off; try_files $uri $uri/ =404; } }The
try_filesline is part of Ubuntu’s sample configuration; it is not required merely to disable directory listings. - Check the configuration and reload. After saving the file, run
sudo nginx -tas a syntax check if it is available in your administration routine, then reload using Ubuntu’s documented command:sudo systemctl reload nginxA reload applies the new configuration without the stop-and-start cycle of a full restart.
- Verify both behaviors. Request a slash-ending directory URL that has no index file, and request a normal page that should resolve to an index file. Use a browser or an HTTP client and confirm that the generated file list is gone while expected pages still work.
What Nginx autoindex controls
It generates listings for directory requests
The autoindex module handles requests whose URI ends with a slash, such as /downloads/. Nginx generally reaches this module after its index processing cannot find an index file. When enabled, it creates an HTML listing of the directory contents. The official directive description is: “Enables or disables the directory listing output.”
This behavior is different from serving a file whose name is already known. Turning listings off does not prevent Nginx from serving /downloads/manual.pdf when that file is otherwise available. It only removes the generated directory view.
#1 Best Overall
The documented default is off
Nginx defines the directive as autoindex on | off; and documents autoindex off; as the default. It is valid in http, server, and location contexts. Explicitly writing off is still useful: it makes the intended policy visible and overrides an on setting inherited from a broader block.
| Context | Effect | When to use it |
|---|---|---|
http |
Applies as a broad default to servers in that HTTP configuration. | Use when every hosted site should have listings disabled unless a narrower block changes the value. |
server |
Applies to one virtual server and its locations unless overridden. | Useful when one hostname needs a consistent policy. |
location |
Applies to the selected URL path. | Usually the safest choice when only one directory or route is affected. |
Find the configuration that actually handles the request
Editing a file is effective only if its server block is selected for the hostname and URI you are testing. Ubuntu’s supplied single-site configuration is /etc/nginx/sites-enabled/default. A multi-site installation commonly keeps editable files in /etc/nginx/sites-available/ and enables them with symbolic links in /etc/nginx/sites-enabled/. The enabled link, not an unused file in sites-available, determines what Nginx loads.
Open the enabled file and locate its server { ... } block, including its listen, server_name, root, and location directives. If several sites are enabled, match the hostname you put in the browser. A setting in the default server will not necessarily control a request routed to another named server.
Do these 3 things before closing this tab:
1Scan for outdated or missing drivers - takes under a minute2Clear out junk files and repair common Windows errors3Fix the driver behind crashes, sound loss and screen glitchesTo find an existing explicit setting, search the enabled configuration and the main Nginx configuration for autoindex. Treat comments such as #autoindex on; as examples or notes, not active directives. The effective setting is the uncommented directive in the block Nginx selects, together with any inherited value from a wider context.
Choose the right placement for autoindex off
Disable listings everywhere on one site
Put the directive directly inside the site’s server block when every path on that hostname should reject generated listings:
server {
listen 80;
server_name example.test;
root /var/www/example;
autoindex off;
location / {
try_files $uri $uri/ =404;
}
}Keep the existing directives that define the site’s listener, hostname, document root, and routing. The important change for this task is the explicit autoindex off;.
Disable it only for a directory
Use a matching location when another part of the site has a different requirement. For a directory such as /files/:
location /files/ {
autoindex off;
}This limits the policy to requests handled by that location. If a more specific location processes the request, place the directive there instead. Nginx’s location selection and internal redirects can make the final processing block different from the one you first inspect.
Set a broad default in the http block
An http-level directive can establish a default for all virtual servers:
http {
autoindex off;
# server blocks follow
}Use this only when that broad behavior is intentional. A server- or location-level autoindex on; can still override it for a narrower area.
Reload Nginx and test the result
Reload, do not assume a saved file is active
Nginx reads configuration at startup or reload. Saving a file alone does not change the running workers. Run:
sudo systemctl reload nginxIf the reload reports an error, correct the configuration before relying on the result. A syntax check with sudo nginx -t can identify malformed directives or braces before you reload. Do not remove unrelated directives simply because the listing problem is in one location.
Use a meaningful directory test
Test a URL ending in a slash, for example https://example.test/files/, where the directory has no index file. That is the case in which Nginx would otherwise generate a listing. A request without the trailing slash may be redirected or handled differently, so it is not an equivalent test.
Then request an ordinary page, such as the site’s root URL, that should resolve to an index file. This second test catches accidental routing changes while you are editing the server block.
Understand index files versus generated listings
An index file is a separate mechanism
Nginx’s index module uses index.html as its documented default filename. Ubuntu’s sample server block lists index.html, index.htm, and index.nginx-debian.html. If one of those files exists and is selected, Nginx serves it instead of creating a directory listing.
What’s actually slowing this PC down?
Pick the symptom - the matching free tool is one click away.
Rank #4
Disabling autoindex does not create an index file and does not change which index filenames are configured. If you want a deliberate landing page, create or deploy an index file and configure the appropriate index directive separately.
Why a directory may not return 404
The documented effect of autoindex off; is to disable listing output, not to prescribe a particular status code. Depending on the rest of the active configuration, a directory request might produce a 403, a 404, a redirect, an application response, or another configured result. Do not treat a 404 as an automatic promise of this directive.
Internal redirects can change the processing location
Nginx’s index processing can issue an internal redirect after it selects an index filename. The redirected request may then be handled by a different location block. This explains cases in which the original directory location appears correct but the eventual response follows another block’s rules. Inspect the complete active server configuration when the observed result does not match the block you edited.
Independent reader supportYour contribution helps us test, update, and keep practical guides available for everyone.Troubleshoot a listing that is still visible
The wrong site file was edited
Confirm that the hostname in the request matches the server_name of the edited block and that the file is enabled through sites-enabled. In a multi-site installation, a change in /etc/nginx/sites-available/example.test has no effect if its enabled link is missing or points elsewhere.
A narrower block enables autoindex
Search for every uncommented autoindex on; in the loaded configuration. A location-level setting takes precedence for requests handled there, even if you set off in the server block. Move the explicit off into the location that actually serves the directory, or remove the narrower on when it is no longer needed.
Best Value
The request is not reaching the directory you think it is
Check the URL path, trailing slash, and the server’s root. An application or a separate location may be responding instead of the filesystem directory. Compare the directory URL with a known static file under the same path to establish which part of the configuration is serving the request.
The page changed but a browser shows an old result
Request the URL again with a fresh browser session or an HTTP client, and verify that the reload command completed successfully. A cached page can make a removed listing appear to persist even after Nginx has loaded the new setting.
Ubuntu 24.04 version context and operational limits
Ubuntu 24.04 LTS release notes identify Nginx 1.24 for that release. The directive behavior described here comes from upstream Nginx documentation; a customized installation, alternate package, container, or manually built binary can have a different surrounding configuration. Check the effective configuration on the host you administer rather than assuming every installation uses Ubuntu’s sample file.
Crashes, No Sound, or Screen Glitches?
Random freezes, missing sound and display glitches usually trace back to one bad driver. Find and replace yours safely.Free scan · under a minutePC Slower Than It Used to Be?
A free scan shows the junk files, broken settings and background clutter dragging Windows down - then fixes them in one click.Free scan · Windows 10 & 11No additional Nginx module or separate package is required for this setting. The task is a configuration change: identify the active block, set autoindex off;, reload, and verify the directory URL. Keep in mind that listing suppression is not a substitute for access control. It hides Nginx’s generated index, but it does not by itself prevent a user who knows a filename from requesting that file, nor does it replace authentication or authorization rules.
Quick Recap
Practical checklist
- Locate the enabled server configuration for the hostname and path.
- Check for an active
autoindex on;in a broader or narrower context. - Add
autoindex off;in the smallest block that should enforce the policy. - Leave index-file and routing directives unchanged unless you have a separate reason to modify them.
- Run a configuration syntax check, then execute
sudo systemctl reload nginx. - Test a slash-ending directory with no index file and a normal index-file page.
- If the result is unexpected, inspect location selection, enabled symlinks, and the effective configuration rather than assuming the directive failed.
Product prices and availability are accurate as of the date/time indicated and are subject to change. Any price and availability information displayed on Amazon at the time of purchase will apply.
