elecV2P Review: MITM Request Rules and Scheduled Scripts

elecV2P's Network Control Surface

elecV2P is built for people who want to alter network requests and automate actions around them. The README identifies four core areas: MITM request viewing and modification, scheduled JavaScript or shell execution, FEED/IFTTT/custom notifications, and EFSS file management. The intended user is therefore not a casual web dashboard user. The project assumes familiarity with Node.js, HTTP proxying, HTTPS certificates, cron expressions, and files containing executable scripts.

The network layer uses AnyProxy. The default port layout separates the Vue web interface, the HTTP proxy, and a request-viewing endpoint. Port 80 serves the webUI, port 8001 is the AnyProxy HTTP proxy, and port 8002 is used to view proxied requests. AnyProxy is disabled by default according to the README and can be enabled temporarily by double-clicking the AnyProxy entry on the webUI home page, or enabled during initialization from the settings interface.

This design is useful when the goal is local control over requests, such as applying RULES or REWRITE actions. It is also a meaningful security decision. The README warns that the program has broad permissions and recommends LAN use, while public deployment requires reading Advanced.md and accepting the stated risk. The tool is not limited to reading traffic. Its MITM feature can inspect and modify HTTPS traffic after a root certificate has been trusted, and its task system can execute shell commands. Those capabilities make network placement and OS permissions part of the product design, not incidental configuration details.

Rules, Certificates, and HTTPS Interception

HTTPS inspection depends on a root certificate with the fixed filenames rootCA.crt and rootCA.key. The README says these files are stored under $HOME/.anyproxy/certificates and can be downloaded through the web interface, the MITM installation path, or port 8002. A user who does not need RULES or REWRITE can skip the certificate step. A user who does need HTTPS request modification must install and trust the root certificate on each client that will be intercepted.

The certificate instructions call for more than copying a file. Windows users are directed to choose the Trusted Root Certification Authorities store. When a different certificate is adopted, the README instructs users to install and trust the new certificate and clear domain certificates issued by the previous root. That requirement is a direct consequence of certificate replacement. Clients can retain trust relationships tied to the old root, producing confusing failures when the service starts using new keys.

The README also permits uploading a self-signed root certificate through the MITM interface, followed by an elecV2P restart. This is useful for organizations that already manage certificates, but it gives the operator control over a security-sensitive trust anchor. The README does not document an automatic certificate rotation policy or a safe rollback procedure for certificate replacement. Operators should therefore treat rootCA.crt, rootCA.key, client certificate stores, and the old certificate cleanup step as one operational unit. The repository contains rootCA/ and web-related directories, but the README does not provide enough detail to infer more specific certificate lifecycle behavior.

Scheduled Tasks and Notification Paths

elecV2P supports two scheduling styles: countdown scheduling and cron scheduling. A countdown has up to four fields separated by spaces: the base delay, optional repeat count, optional random extra delay, and optional random repeat count. The README gives 40 8 10 3 as an example. It describes that value as running after approximately 40 to 50 seconds, repeated between 8 and 11 times. A repeat count of 999 or more means infinite looping.

Cron accepts five or six fields, with seconds optional. The documented fields cover seconds, minutes, hours, day of month, month, and day of week. Tasks can run JavaScript, start or stop other scheduled tasks, or execute basic shell commands. Examples include rm -f *, python test.py, and reboot. Those examples explain the supported task model, but they also show why task contents require review. A script stored through the web interface may have access to the same files and operating-system permissions as the elecV2P process.

Notifications can be sent through FEED/RSS, IFTTT WEBHOOK, BARK, or custom notification mechanisms. The webUI exposes a feed at /feed. Notification events include task start, task end, JavaScript execution counts, and notification calls made by scripts. This creates a useful audit surface for automation, although the README does not state whether notification delivery is retried, signed, or restricted to particular destinations. It also does not document a separate role-based permission model for shell tasks. The appropriate operational boundary is consequently the account and host on which elecV2P runs.

Docker Compose Setup and Persistent Data

The README identifies Docker Compose as the recommended installation method when Docker is available. The following is the documented Compose workflow for creating a data directory and downloading docker-compose.yaml. The directory paths in the Compose file are then mounted into the container for scripts, lists, storage, shell files, certificates, and EFSS data.

mkdir /elecv2p && cd /elecv2p
curl -sL https://git.io/JLw7s > docker-compose.yaml
docker-compose up -d

The Compose configuration maps host ports 8100, 8101, and 8102 to container ports 80, 8001, and 8002. It sets TZ=Asia/Shanghai and persists six paths, including /elecv2p/rootCA and /elecv2p/efss. After saving the file, the README documents these startup and update commands:

docker-compose up -d
docker-compose pull elecv2p && docker-compose up -d

The volume mappings retain personal data, scripts, certificates, and EFSS files outside the container. The README warns that deleting or replacing a container without persistent storage can lose data. The ARM32 note adds a separate boundary: GitHub Actions has not produced ARM32 Docker images since v3.7.3, so ARM32 users are directed toward the soft update script instead. That is a concrete compatibility limitation rather than a general maintenance claim.

The repository has no GitHub releases, but the last push was on 2026-09-12. That date indicates recent repository activity, not a published release cadence. Upgrade instructions include both softupdate.js and a manual backup, git pull, and restore procedure. The README marks manual upgrading as not recommended, but it still requires backup and restoration of personal data.

Direct Node.js Operation and PM2 Control

For users who do not want Docker, the README requires Node.js version 14.17.0 or newer and uses Yarn to install dependencies. The documented direct startup path is:

git clone https://github.com/elecV2/elecV2P.git
cd elecV2P
yarn
yarn start

The package.json start script invokes PM2 with index.js and the name elecV2P. A direct alternative is node index.js. The README documents port and time-zone overrides for cases where port 80 is unavailable:

PORT=8000 TZ=Asia/Shanghai node index.js

On Windows, it gives separate CMD and PowerShell forms for setting PORT. The time zone is explicitly controlled with TZ=Asia/Shanghai in the documented example. PM2 commands cover stopping or restarting the named process, listing processes, and viewing raw logs.

pm2 restart elecV2P
pm2 ls
pm2 logs --raw

The direct Node.js route leaves more responsibility with the operator than the Compose file. The operator must install Node.js, Yarn, PM2, and any operating-system dependencies needed by scheduled shell commands. The README estimates roughly 90 MB for files and dependencies and approximately 90 MB of initial memory use, with a reference figure of about 150 MB for 100 scheduled tasks. It explicitly labels those figures as approximate and dependent on software and hardware, so they should not be treated as capacity guarantees.

Alternative Tools and Adoption Boundaries

The closest functional alternative is a conventional reverse proxy such as Nginx, combined with a separate scheduler or automation service. That approach does not provide elecV2P's integrated webUI, AnyProxy request viewer, MITM rules, FEED/RSS, and task controls in one package. It does, however, separate network traffic management from arbitrary script execution.

Another alternative is a dedicated MITM inspection tool paired with a task scheduler. A dedicated inspection tool is easier to scope when the requirement is only request capture or rewriting. elecV2P becomes more relevant when the same private host must inspect traffic, maintain user-authored JS and shell tasks, expose notification events, and manage EFSS files through one interface.

There are clear cases where elecV2P is the wrong tool. It should not be placed on an untrusted LAN merely to provide a shared proxy, because the README's own warning says the program has extensive permissions. It is also a poor fit for a production service that needs documented access control, certificate rotation, rollback, or narrowly audited shell execution, since those controls are not established by the README. The Vue primary-language designation largely describes the web interface, while the operational core is Node.js and AnyProxy. That distinction matters when reviewing deployment requirements or support expectations.

Editorial conclusion

elecV2P fits a user who needs a private request-modification proxy with scheduled scripts and already understands TLS interception, process permissions, backups, and Docker persistence. It is unsuitable for an untrusted network, an unattended production proxy, or users seeking a narrowly scoped dashboard. Verify the Docker volumes, certificate handling, exposed ports, backup procedure, and exact task permissions before adopting it.

Frequently asked questions

Official sources

1. elecV2/elecV2P on GitHub
2. Issues
3. Project website
4. README