# techchipnet/ip-changer architecture

> Architecture diagram of the GitHub repository techchipnet/ip-changer, generated by GitDiagram from its file tree, README and a sample of source files (last updated 2026-06-17). It is an AI-made overview: check details against the source.

- Interactive diagram: https://gitdiagram.com/techchipnet/ip-changer
- Repository: https://github.com/techchipnet/ip-changer

## Overview

This repository is a small Linux automation tool, not a multi-tier application. Its architecture is centered on a shell-script runtime plus a systemd service that repeatedly forces outbound traffic through Tor to rotate the apparent IP address.

1. Core purpose  
The system automates IP rotation at a user-defined interval. The main runtime behavior is: start Tor, periodically request a new Tor circuit/identity, and verify the resulting public IP change.

2. Main artifacts in the repo  
- `change_tor_ip.sh`: the core long-running script that performs the IP-change loop.  
- `change-tor-ip.service`: the systemd unit that keeps the script running in the background.  
- `setup.sh`: installation/setup path for deploying the service.  
- `ip-changer.sh`: an alternate “run without installation” entry point, used directly from the repo.

3. Execution model  
The project is shell-script driven and runs on Linux with `sudo` privileges. There is no compiled binary, daemon framework, database, or web frontend. The service boundary is systemd, which manages lifecycle, autostart, and background execution.

4. Runtime flow  
User selects an interval during setup. The setup path installs/places the script, configures the service, and enables it. At runtime, systemd starts `change_tor_ip.sh`, which then loops on the configured interval and triggers IP rotation through Tor.

5. Interaction with Tor  
Tor is the key external subsystem. The scripts depend on the local Tor service and on Tor’s ability to establish new circuits/identities. The repo’s architecture assumes Tor is installed and available on the host machine rather than embedded in the application.

6. IP verification path  
The README lists `curl`, `xxd`, and `fq` as prerequisites, so the scripts likely use command-line HTTP requests and text processing to check the current public IP and to detect when a new exit node has taken effect. That makes the external IP-check service part of the data flow.

7. Service management boundary  
`change-tor-ip.service` is the operational control point. It determines how the script is started, whether it restarts, and how it behaves under systemd. The README’s instructions for status/start/stop/disable imply the service is the intended long-lived deployment mode.

8. Installation vs. direct run  
There are two supported paths: a direct execution path via `ip-changer.sh`, and a persistent deployment path via `setup.sh` plus systemd. Both paths appear to converge on the same core logic in `change_tor_ip.sh`, but they differ in lifecycle management.

9. Configuration boundary  
The only user-facing configuration explicitly mentioned is the interval for IP changes. That setting is likely baked into the service definition or written by the setup script into the runtime script/service unit. This is the main configurable input to the system.

10. Operational dependencies  
The architecture depends on Linux distribution packaging and init/service management, but not on any cloud service or backend. The supported distros listed in the README indicate the scripts are designed to be portable across common systemd-based Linux environments.

11. Security and network considerations  
The tool routes traffic through Tor for anonymity, but the README notes that exit nodes can be blocked and performance can be slower. This means network reliability and website filtering are external constraints on the architecture, not internal failures.

12. High-level diagram view  
A good architecture diagram would show: user → setup script or direct launcher → systemd service → core IP-rotation shell script → local Tor service → external IP-check endpoint. The system’s main state is the running service and the timing interval; its only external dependencies are Tor and command-line utilities.

Main entry points: [`change_tor_ip.sh`](https://github.com/techchipnet/ip-changer/blob/main/change_tor_ip.sh) (change_tor_ip.sh), [`change-tor-ip.service`](https://github.com/techchipnet/ip-changer/blob/main/change-tor-ip.service) (systemd unit), [`setup.sh`](https://github.com/techchipnet/ip-changer/blob/main/setup.sh) (setup.sh), [`ip-changer.sh`](https://github.com/techchipnet/ip-changer/blob/main/ip-changer.sh) (ip-changer.sh)

## Diagram (Mermaid)

```mermaid
flowchart TD

subgraph group_group_runtime["Runtime path"]
  node_service_unit["systemd unit<br/>service config"]
  node_core_script["change_tor_ip.sh<br/>rotation loop<br/>[change_tor_ip.sh]"]
  node_tor_service[("Tor service<br/>local anonymity service")]
  node_ip_check(("IP check<br/>external endpoint"))
  node_cli_tools["CLI utils<br/>shell dependencies"]
end

subgraph group_group_setup["Deployment path"]
  node_setup_sh["setup.sh<br/>installer shell<br/>[setup.sh]"]
  node_ip_changer_sh["ip-changer.sh<br/>direct launcher<br/>[ip-changer.sh]"]
end

node_user(("User<br/>operator"))

node_user -->|"installs"| node_setup_sh
node_user -->|"runs"| node_ip_changer_sh
node_setup_sh -->|"installs"| node_service_unit
node_setup_sh -->|"configures"| node_core_script
node_ip_changer_sh -->|"delegates"| node_core_script
node_service_unit -->|"starts"| node_core_script
node_core_script -->|"requests identity"| node_tor_service
node_core_script -->|"verifies IP"| node_ip_check
node_core_script -->|"uses"| node_cli_tools
node_tor_service -->|"routes through"| node_ip_check
node_service_unit -.->|"managed by"| node_setup_sh
node_user -.->|"controls"| node_service_unit

click node_setup_sh "https://github.com/techchipnet/ip-changer/blob/main/setup.sh"
click node_ip_changer_sh "https://github.com/techchipnet/ip-changer/blob/main/ip-changer.sh"
click node_service_unit "https://github.com/techchipnet/ip-changer/blob/main/change-tor-ip.service"
click node_core_script "https://github.com/techchipnet/ip-changer/blob/main/change_tor_ip.sh"

classDef toneNeutral fill:#f8fafc,stroke:#334155,stroke-width:1.5px,color:#0f172a
classDef toneBlue fill:#dbeafe,stroke:#2563eb,stroke-width:1.5px,color:#172554
classDef toneAmber fill:#fef3c7,stroke:#d97706,stroke-width:1.5px,color:#78350f
classDef toneMint fill:#dcfce7,stroke:#16a34a,stroke-width:1.5px,color:#14532d
classDef toneRose fill:#ffe4e6,stroke:#e11d48,stroke-width:1.5px,color:#881337
classDef toneIndigo fill:#e0e7ff,stroke:#4f46e5,stroke-width:1.5px,color:#312e81
classDef toneTeal fill:#ccfbf1,stroke:#0f766e,stroke-width:1.5px,color:#134e4a
class node_service_unit,node_core_script,node_tor_service,node_ip_check,node_cli_tools toneBlue
class node_setup_sh,node_ip_changer_sh toneAmber
class node_user toneNeutral
```

## Components

### Runtime path

Long-lived IP rotation flow and external dependencies.

- [systemd unit](https://github.com/techchipnet/ip-changer/blob/main/change-tor-ip.service): service config · Keeps the rotation script running and manages lifecycle. · `change-tor-ip.service`
- [change_tor_ip.sh](https://github.com/techchipnet/ip-changer/blob/main/change_tor_ip.sh): rotation loop · Main long-running loop that requests new Tor identity and checks IP. · `change_tor_ip.sh`
- **Tor service**: local anonymity service · Provides circuits and new exit nodes for outbound traffic.
- **IP check**: external endpoint · Public IP verification target used to confirm rotation.
- **CLI utils**: shell dependencies · curl, xxd, fq, and other command-line helpers used by the scripts.

### Deployment path

Installation and direct-launch entry points.

- [setup.sh](https://github.com/techchipnet/ip-changer/blob/main/setup.sh): installer shell · Installs and configures the systemd service and interval. · `setup.sh`
- [ip-changer.sh](https://github.com/techchipnet/ip-changer/blob/main/ip-changer.sh): direct launcher · Runs the tool without installation. · `ip-changer.sh`

### Other components

- **User**: operator · Starts setup or launches the tool directly.

## Connections

- User → setup.sh: installs · User runs setup to deploy the service and choose an interval.
- User → ip-changer.sh: runs · User can launch the script directly without installation.
- setup.sh → systemd unit: installs · Setup writes or enables the systemd service definition.
- setup.sh → change_tor_ip.sh: configures · Setup prepares the runtime script and interval settings.
- ip-changer.sh → change_tor_ip.sh: delegates · Direct launcher converges on the same rotation logic.
- systemd unit → change_tor_ip.sh: starts · systemd launches and supervises the rotation loop.
- change_tor_ip.sh → Tor service: requests identity · Script asks Tor for new circuits or exit nodes.
- change_tor_ip.sh → IP check: verifies IP · Script checks that the public IP has changed.
- change_tor_ip.sh → CLI utils: uses · Shell pipeline relies on command-line HTTP and text tools.
- Tor service → IP check: routes through · Traffic exits through Tor before reaching the IP check target.
- systemd unit → setup.sh: managed by · The unit is installed and enabled by the setup path.
- User → systemd unit: controls · User can start, stop, disable, or inspect the service.