# Alist-encrypt WebDAV Encryption Proxy Review

> Alist-encrypt is a Node.js proxy that encrypts selected AList WebDAV uploads and decrypts files during downloads or media playback. It suits private cloud-storage users, but the README still describes it as beta and not ready for production.

**traceless/alist-encrypt** — 这个项目主要是对 alist 的服务进行代理，提供 webdav 的加解密功能。支持 alist 网页在线播放加密的视频，查看加密的图片等功能，同时在 webdav 下的操作透明，自动实现文件资源的加解密。

- Repository: https://github.com/traceless/alist-encrypt
- Stars: 1,507 · Forks: 148
- Language: JavaScript
- License: not declared
- Published: 2026-10-16 · Updated: 2026-10-16 · Language: en
- Canonical page: https://hysenlabs.com/projects/traceless-alist-encrypt

## Why Alist-encrypt Sits Between AList and WebDAV

Alist-encrypt addresses a storage conflict rather than implementing a general-purpose encryption library. A user can encrypt a file before uploading it to a cloud drive so that the stored object cannot be opened directly, while still using the WebDAV endpoint exposed by AList for normal uploads, downloads, image viewing, and video playback. Its intended audience is people who use AList with cloud providers and want files in selected directories to resist provider-side scanning or deletion.

The project works as a proxy in front of an existing AList service. The README says that ordinary AList web operations are passed through, but upload paths covered by the encryption rules receive encryption before storage. Later reads through the proxy are decrypted as data is transferred. This arrangement allows an encrypted file to appear broken when downloaded directly from the cloud provider, yet remain usable through the Alist-encrypt-managed AList or WebDAV interface.

This model does not change every request indiscriminately. The administrator selects paths that require encryption, and the README gives `movie_encrypt/*` as the recommended regular-expression form. Files outside those rules retain AList's normal behavior. A broad or incorrect expression could send files through the wrong path-handling branch, and the README does not describe a preview, dry-run, or recovery check for path configuration.

## RC4 and AES-CTR Control the Stream

The current design encrypts streaming data rather than requiring the whole file to be loaded before processing. The README lists two implemented choices, RC4 and AES-CTR. AES-CTR is the documented recommendation, with hardware AES support identified as the preferred CPU configuration. RC4 is offered for compatibility with devices that lack AES instructions. The project removed its earlier MIX obfuscation scheme because the author considered it adequate for cloud-storage use but too weak for encryption because file characteristics could assist recovery.

The streamed architecture is central to the media features. An uploaded video can be decrypted as playback requests arrive, and images can be returned as viewable data without requiring the cloud object itself to be readable. The README says WebDAV operations remain transparent to a client, subject to the configured encryption paths and special handling for encrypted uploads and playback.

Password behavior is more involved than a single global key. The supported-features list says keys can be derived from folder names, and the feature list permits different passwords for different directories. The README does not document key derivation parameters, nonce handling, ciphertext metadata, password recovery, or the exact framing that binds a stream position to AES-CTR. An engineer would need to inspect the source before relying on the software for files without another copy.

## Installing Alist-encrypt with Node.js and Docker

For a local Node.js installation, first install Node.js and download the repository. The README directs users to the `node-proxy` directory and offers two dependency modes. Omitting development dependencies reduces storage use when only the proxy will be run.

```bash
npm i --omit=dev
```

Developers who need the full development and build dependency set can use the documented alternative:

```bash
npm i
```

Next, edit `conf/config.js` to add the AList service address and port plus the cloud-drive folder paths that require encryption. The README does not publish the complete configuration schema, so it does not support reproducing a valid file here. Start the proxy after making those edits:

```bash
npm run serve
```

The first setup page is `http://127.0.0.1:5344/public/index.html`. The documented default credentials are account `admin` and password `123456`. After configuration is completed, the proxied AList service is available at `http://127.0.0.1:5344`.

Docker users can pull and start the beta image. This command maps port 5344 and stores configuration under `/node-proxy/conf` through the mounted `/etc/conf` directory:

```bash
docker pull prophet310/alist-encrypt:beta
```

```bash
docker run -d -p 5344:5344 -v /etc/conf:/node-proxy/conf --name=alist-encrypt prophet310/alist-encrypt:beta
```

The README also supports the initial `ALIST_HOST` environment variable for default AList host configuration. No GitHub releases are listed, and the README describes release versions as forthcoming.

## Configuring Encryption Paths Before the First Upload

Path configuration determines which uploads receive encryption. The interface accepts regular expressions, and the README recommends an expression such as `movie_encrypt/*` for the corresponding directory. There is no documented multi-step configuration wizard beyond opening the configuration page. A new user therefore needs to configure the AList address and path expression before sending a file whose cloud copy must be unreadable.

The expected result is asymmetric by design. A file uploaded through the protected WebDAV path should be encrypted on the cloud drive and unusable when fetched directly, while the same resource downloaded through Alist-encrypt should open normally. Web-based video playback and image viewing should likewise receive decrypted content. The README also states that encrypted media can be handed to IINA, VLC, and Infuse.

Before relying on that behavior, test a disposable file and confirm both retrieval routes. The README does not provide a key export, password reset procedure, or explanation of what happens when the configured folder password is lost. Its feature list mentions a CLI for encrypting or decrypting shared files, but the README gives no installation or invocation syntax for that CLI.

## Media Playback, WebDAV Compatibility, and Proxy Cost

The main benefit is preserving client workflows after content has been encrypted at rest. The README says WebDAV operations remain usable and that AList's existing web operations pass through the proxy. This avoids requiring users to decrypt every file manually before playback. The process still adds a proxy layer between the client and AList, so the deployment host must handle the transferred traffic.

The README gives theoretical capacity figures of 300 Mbps for RC4 on an `s905l3a` CPU and more than 800 Mbps for AES-CTR. These are documented author figures rather than independently established results, and the FAQ frames them as theoretical. They do not account for AList itself, storage-provider throttling, client decoding, TLS termination, or concurrent connections. For high-volume traffic, the proxy host's network and single-core behavior require direct attention.

The README recommends local or LAN deployment partly because the proxy handles file traffic. Installing it directly on the public path of a remote AList service would also make the undocumented default configuration credentials more consequential. The README does not provide a TLS configuration example or explain how the proxy is secured beyond the configuration page, so exposing port 5344 directly should not be inferred to be safe.

## Beta Status, AList Compatibility, and License Constraints

The repository is not archived, and its last push was on 2026-08-14. That date shows recent repository activity, but it does not establish release readiness. There are no GitHub releases, the documented Docker image is tagged `beta`, and the FAQ explicitly says the current version is not ready for production use. It also says several cloud providers remain untested and more development is required.

Upgrade planning is constrained. There is no documented semantic-version history, migration guide, compatibility matrix, or stable image tag. Users who follow AList changes must watch the repository and the feedback group named in the README for compatibility updates, but the README does not define a supported upgrade procedure. The absence of a release artifact also makes it harder to identify which proxy behavior belongs to a tested version.

The repository has an unknown license. Without a stated license, potential adopters cannot confirm what permissions cover modification, redistribution, container use, or derived deployment. This is a direct adoption constraint rather than a legal conclusion. Engineers should inspect the repository for a license file or obtain clarification from its maintainer before redistributing the software or incorporating it into a product.

## Alist-encrypt Versus Client-Side Encryption Tools

A real alternative is to encrypt files in a dedicated client before uploading them to AList and decrypt them locally after download. That approach changes where the trust boundary sits. Instead of routing AList and WebDAV traffic through Alist-encrypt, the client performs encryption and decryption directly, and the AList deployment remains an ordinary storage gateway.

Client-side tools are less convenient for streaming encrypted video and images because the remote server usually serves ciphertext, so random-access media playback would require either a client that understands the encryption format or an additional local decryption and serving layer. Alist-encrypt addresses this gap by decrypting streams as they pass through its proxy and by integrating password behavior with AList paths. Its cost is an additional service, configuration of matching encryption rules, and dependence on the project's beta implementation.

The choice is between media transparency through a proxy and fewer custom components through client-side encryption. Alist-encrypt is more relevant when direct WebDAV playback is the priority. A standalone client is easier to reason about when files can be decrypted after download and the user does not need encrypted online streaming.

## Conclusion

Alist-encrypt fits users who need encrypted cloud-storage uploads while retaining WebDAV access and direct playback through an AList front end. It does not fit production deployments or users who need a documented release process and confirmed license terms. Verify the default configuration credentials, AList compatibility, encryption path coverage, and beta image behavior before storing files without another copy.

## FAQ

### How do I install Alist-encrypt and start the proxy?

Install Node.js, enter `node-proxy`, run `npm i --omit=dev`, edit `conf/config.js`, and start the service with `npm run serve`. The README also documents a Docker image named `prophet310/alist-encrypt:beta`.

### Which encryption algorithm should Alist-encrypt use?

The README recommends AES-CTR, particularly on CPUs with AES instruction support. RC4 is documented as the compatibility choice for devices without AES instructions.

### Is Alist-encrypt ready for production use?

No. The README states that the current version is not ready for production use, several cloud providers remain untested, and additional development is required. No GitHub releases are listed.

## Sources

- [Issues](https://github.com/traceless/alist-encrypt/issues)
- [README](https://github.com/traceless/alist-encrypt/blob/main/README.md)
- [traceless/alist-encrypt on GitHub](https://github.com/traceless/alist-encrypt)

---

Hysen Labs editorial analysis, written from the project's own repository and release notes. Cite the canonical page: https://hysenlabs.com/projects/traceless-alist-encrypt