Why Audiobookshelf adds /audiobookshelf to your URL, and the 'Dangerous site' warning

Audiobookshelf v2.18.0 added support for running under a subfolder, and the standard builds use /audiobookshelf for it. So when you open https://books.example.com, the web page moves you to https://books.example.com/audiobookshelf/. Nothing is broken; that’s where the web page lives now.

Phone apps aren’t affected. The server still answers at the old addresses, and the apps talk to the server directly, not through the web page.

The red “Dangerous site” warning some people see is a separate thing: Google’s Safe Browsing list has flagged the address. You clear it by asking Google for a review, covered below.

Why did my Audiobookshelf URL change to /audiobookshelf?

Subfolder support lets people run Audiobookshelf at example.com/audiobookshelf next to other sites. To make that work, the server adds /audiobookshelf to any request that doesn’t have it.

That means:

• Old bookmarks and links still work. They just land on the /audiobookshelf/ address.
• A subdomain such as books.example.com keeps working. A typical reverse proxy setup needs no changes; only unusual routing rules might.
• The server’s API answers both with and without /audiobookshelf. A project contributor confirmed in issue #3874 that the change only affects the web client and OpenID sign-in, not the apps.

Do I need to change the address in my app?

No. Keep the address you already use, such as https://books.example.com. The server answers with or without /audiobookshelf on the end.

The one case where the path belongs in the app is a server you set up in a subfolder of a shared domain, like https://example.com/audiobookshelf. Then type it with the subfolder. What to type as your server address covers SoundLeaf’s sign-in screen.

OpenID sign-in in a browser is pickier: on a standard install, the return address after sign-in has to be on your server and under /audiobookshelf/. If you see “Invalid callback URL - must be same-origin”, see OpenID login errors.

Can I turn off the /audiobookshelf path?

Not with the standard Docker image or packages. The server reads a ROUTER_BASE_PATH setting, but the web page is built ahead of time with /audiobookshelf written into it. Change the setting on a standard install and the web page breaks.

The only way to use a different path, or none, is to build the web client yourself with the same ROUTER_BASE_PATH value. People in issue #3874 have posted Dockerfiles for that, but it’s a custom build you’d have to keep up to date with every release. The issue is still open.

If you run it at your own subfolder through a reverse proxy, use /audiobookshelf. The reverse proxy guide has the settings.

Why does my browser say my Audiobookshelf server is a dangerous site?

Browsers that use Google Safe Browsing, Chrome among them, show a red warning page, such as “Dangerous site”, when Google lists an address as unsafe. Several people running Audiobookshelf have had their server flagged, often on the /audiobookshelf/login page, with Google’s reason given as deceptive or social engineering content.

Nobody has found a single cause. The reports in issue #4624 include servers behind Cloudflare and servers using OpenID sign-in. One person thinks Gmail flagged an email that contained their server address and a sign-in link. The project owner saw an unrelated admin site at work flagged the next day, which suggests a change on Google’s side rather than something in Audiobookshelf.

How do I get the warning removed?

You ask Google to review your site in Search Console.

1. Go to Google Search Console and add your domain. You’ll need to prove you own it, usually with a DNS record.
2. Open the Security issues report. It explains what Google found and may show example pages.
3. Check those pages, and anything else on the same domain, for content you didn’t put there. Fix anything you find.
4. Click Request review. Say what you checked or fixed, and that the flagged page is the sign-in page of your own self-hosted Audiobookshelf server.

Google’s help page says a review can take from a few days to a few weeks, and you’ll get an email when it’s done. Wait for that answer before sending another request. People in the issue have had the flag cleared this way, though for some it came back later.

If you don’t need the server open to the whole internet, you can turn off its public access and connect through a VPN such as Tailscale instead. See listening away from home.