CLI Proxy API Setup

This note records a CLI Proxy API setup.

Example values:

• config directory: /root/.cli-proxy-api
• install directory: /root/cliproxyapi
• public domain: cpa.example.com
• HTTPS port: 8317
• management URL: https://cpa.example.com:8317/management.html
• API endpoint: https://cpa.example.com:8317/v1
• API key: sk-example-cpa-key-please-change
• remote management secret: example_remote_management_secret_change_me

All secrets above are fake.

Sync Config

If you prepare config locally and sync it to the server:

1

rsync -avzP --exclude='logs/*' ~/.cli-proxy-api/ root@198.51.100.20:~/.cli-proxy-api/

Lock down the config directory:

1
2
3

chmod 700 ~/.cli-proxy-api
chmod 600 ~/.cli-proxy-api/config/config.yaml
chmod 600 ~/.cli-proxy-api/*.json

Install

1

curl -fsSL https://raw.githubusercontent.com/brokechubb/cliproxyapi-installer/refs/heads/master/cliproxyapi-installer | bash

Then enter the install directory:

1

cd /root/cliproxyapi

Login Providers

Run only the login flows you need:

1
2
3
4
5

./cli-proxy-api --login           # Gemini
./cli-proxy-api --codex-login     # OpenAI
./cli-proxy-api --claude-login    # Claude
./cli-proxy-api --qwen-login      # Qwen
./cli-proxy-api --iflow-login     # iFlow

These login artifacts are credentials. Keep the auth directory private.

config.yaml

Example config:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47

host: "0.0.0.0"
port: 8317

tls:
  enable: true
  cert: "/root/.cli-proxy-api/config/certs/fullchain.pem"
  key: "/root/.cli-proxy-api/config/certs/privkey.pem"

remote-management:
  allow-remote: true
  secret-key: "example_remote_management_secret_change_me"
  disable-control-panel: false
  disable-auto-update-panel: true
  panel-github-repository: "https://github.com/router-for-me/Cli-Proxy-API-Management-Center"

auth-dir: "/root/.cli-proxy-api"

api-keys:
  - "sk-example-cpa-key-please-change"

debug: false
pprof:
  enable: false
  addr: "127.0.0.1:8316"

commercial-mode: true
logging-to-file: true
logs-max-total-size-mb: 0
error-logs-max-files: 10
usage-statistics-enabled: true
proxy-url: ""
force-model-prefix: false
passthrough-headers: false
request-retry: 3
max-retry-credentials: 2
max-retry-interval: 30
disable-cooling: false
auth-auto-refresh-workers: 2

routing:
  strategy: "round-robin"
  session-affinity: false
  session-affinity-ttl: "1h"

ws-auth: false
enable-gemini-cli-endpoint: false
nonstream-keepalive-interval: 0

Service Management

Console mode:

1

./cli-proxy-api

User systemd service:

1
2
3

systemctl --user enable cliproxyapi.service
systemctl --user start cliproxyapi.service
systemctl --user status cliproxyapi.service

Restart after config changes:

1

systemctl --user restart cliproxyapi.service

Access

1
2

Management Center: https://cpa.example.com:8317/management.html
API Endpoint:      https://cpa.example.com:8317/v1

Test:

1
2

curl https://cpa.example.com:8317/v1/models \
  -H "Authorization: Bearer sk-example-cpa-key-please-change"

Notes

• api-keys, login files, and provider refresh tokens are secrets.
• If TLS is handled inside CLI Proxy API, renew and deploy certificate files consistently.
• If Caddy handles TLS instead, bind CLI Proxy API to localhost and disable internal TLS.
• Keep pprof on 127.0.0.1 only.

DS2API Docker Compose Setup

This note records a DS2API deployment with Docker Compose.

Example values:

• public domain: ds2api.example.com
• public HTTPS port: 8446
• app port inside container: 5001
• host port bound to localhost: 6011
• admin key: example_ds2api_admin_key_change_me
• API key: sk-example-ds2api-key-please-change

All keys above are fake.

Clone

1
2
3
4

git clone https://github.com/CJackHwang/ds2api.git
cd ds2api
cp .env.example .env
cp config.example.json config.json

Environment

Edit .env:

1
2
3
4
5

PORT=5001
DS2API_HOST_PORT=6011
LOG_LEVEL=INFO
DS2API_ADMIN_KEY=example_ds2api_admin_key_change_me
DS2API_CONFIG_PATH=/app/config.json

The app listens on PORT inside the container. DS2API_HOST_PORT is the host-side port used by Docker Compose.

Prefer binding the host port to localhost:

1
2

ports:
  - "127.0.0.1:6011:5001"

config.json

Minimal example:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28

{
  "keys": [
    "sk-example-ds2api-key-please-change"
  ],
  "api_keys": [
    {
      "key": "sk-example-ds2api-key-please-change",
      "name": "main",
      "remark": "for OpenAI-compatible clients"
    }
  ],
  "accounts": [
    {
      "name": "main-account",
      "email": "deepseek-user@example.com",
      "password": "example-password-please-change"
    }
  ],
  "model_aliases": {
    "gpt-4o": "deepseek-v4-flash",
    "gpt-5": "deepseek-v4-pro"
  },
  "runtime": {
    "account_max_inflight": 2,
    "account_max_queue": 5,
    "token_refresh_interval_hours": 6
  }
}

DeepSeek account passwords and refresh tokens are credentials. Treat config.json as a secret file.

Start

1
2

docker compose up -d
docker compose logs -f

Check logs:

1

docker logs --tail 200 -f ds2api

Caddy Reverse Proxy

1
2
3

ds2api.example.com:8446 {
    reverse_proxy 127.0.0.1:6011
}

Reload:

1
2

sudo caddy validate --config /etc/caddy/Caddyfile
sudo systemctl reload caddy

Open the firewall port if needed:

1

sudo nft add rule inet filter input tcp dport 8446 accept

Test

1
2

curl https://ds2api.example.com:8446/v1/models \
  -H "Authorization: Bearer sk-example-ds2api-key-please-change"

Chat completion:

1
2
3
4
5
6
7
8

curl https://ds2api.example.com:8446/v1/chat/completions \
  -H "Authorization: Bearer sk-example-ds2api-key-please-change" \
  -H "Content-Type: application/json" \
  -d '{
    "model": "deepseek-v4-flash",
    "messages": [{"role": "user", "content": "ping"}],
    "stream": false
  }'

Notes

• Change DS2API_ADMIN_KEY; do not leave a default admin password.
• Keep config.json private because it stores upstream account credentials.
• Bind the service to 127.0.0.1 and publish it through Caddy.
• Do not paste real sk-... keys into public docs.

New API Docker Compose Setup

This note records a minimal New API deployment with Docker Compose.

Example values:

• public domain: newapi.example.com
• public HTTPS port: 8445
• container app port: 3000
• repo: https://github.com/QuantumNous/new-api.git

The domain and port are examples. Replace them with your own values.

Install Docker

If Docker is not installed yet:

1
2

curl -fsSL https://get.docker.com -o get-docker.sh
sudo sh get-docker.sh

Check it:

1
2

docker version
docker compose version

Clone

1
2

git clone https://github.com/QuantumNous/new-api.git
cd new-api

Review the compose file before starting it:

1

vim docker-compose.yml

For a reverse-proxy setup, bind the app to localhost if the compose file allows it:

1
2

ports:
  - "127.0.0.1:3000:3000"

If the upstream compose file also starts MySQL and Redis, keep their ports internal unless you have a reason to expose them.

Start

1

docker compose up -d

Check status:

1
2
3

docker compose ps
docker compose logs -f new-api
docker compose logs --tail=100 new-api

For first-time initialization, open the web page and follow the setup wizard:

1

https://newapi.example.com:8445

If you test without Caddy first, use:

1

http://198.51.100.20:3000

198.51.100.20 is a documentation IP address.

Caddy Reverse Proxy

Caddy config:

1
2
3

newapi.example.com:8445 {
    reverse_proxy 127.0.0.1:3000
}

Reload Caddy:

1
2

sudo caddy validate --config /etc/caddy/Caddyfile
sudo systemctl reload caddy

Open the firewall port if needed:

1

sudo nft add rule inet filter input tcp dport 8445 accept

Update

1
2
3
4
5

cd /opt/new-api
git pull
docker compose pull
docker compose up -d
docker image prune -f

If you modified tracked files directly and git pull complains, either move local changes into override files or clean the tree intentionally. Do not blindly reset --hard unless you know what you are throwing away.

Logs

1
2
3
4
5
6
7
8
9
10

# all services
docker compose logs -f

# selected services
docker compose logs -f new-api
docker compose logs -f mysql
docker compose logs -f redis

# foreground debug
docker compose up new-api

AstrBot Service Setup

This note records a minimal AstrBot deployment on a VPS.

Example values:

• service user: astrbot
• working directory: /opt/astrbot
• local port: 6185
• public domain: bot.example.com
• bot token: example-bot-token-please-change
• callback path: /callback/astrbot

Replace all example secrets before using the config.

Install uv

1
2

curl -LsSf https://astral.sh/uv/install.sh | sh
uv --version

Install AstrBot

1
2
3

uv tool install astrbot
command -v astrbot
astrbot --help

If astrbot is installed under the service user's home directory, use the absolute path in the systemd unit.

Environment File

1
2

sudo install -d -m 0750 -o astrbot -g astrbot /opt/astrbot
sudo vim /opt/astrbot/.env

Example .env:

1
2
3
4

BOT_TOKEN=example-bot-token-please-change
CALLBACK_URL=https://bot.example.com/callback/astrbot
ADMIN_ID=10000001
PORT=6185

systemd Unit

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16

[Unit]
Description=AstrBot Service
After=network.target

[Service]
Type=simple
User=astrbot
Group=astrbot
WorkingDirectory=/opt/astrbot
EnvironmentFile=/opt/astrbot/.env
ExecStart=/home/astrbot/.local/bin/astrbot
Restart=always
RestartSec=5

[Install]
WantedBy=multi-user.target

Enable it:

1
2
3

sudo systemctl daemon-reload
sudo systemctl enable --now astrbot
sudo systemctl status astrbot

Reverse Proxy

1
2
3

bot.example.com {
    reverse_proxy 127.0.0.1:6185
}

Logs

1
2

journalctl -u astrbot -e --no-pager
journalctl -u astrbot -f

Cowrie Honeypot Setup

Cowrie is an SSH/Telnet honeypot. It should be treated as hostile-facing software, not as a normal trusted application.

This note records a minimal deployment using a dedicated user, Python venv, and systemd.

Example values:

• honeypot user: cowrie
• internal Cowrie SSH port: 2222
• public SSH trap port: 22 or 2222, depending on firewall/NAT design
• fake hostname shown to attackers: backup-server

Install

Create a dedicated user:

1
2

sudo adduser --disabled-password --gecos "" cowrie
sudo -iu cowrie

Clone and install dependencies:

1
2
3
4
5
6

git clone https://github.com/cowrie/cowrie.git
cd cowrie
python -m venv cowrie-env
source cowrie-env/bin/activate
pip install --upgrade pip
pip install -r requirements.txt

Configure

1
2

cp etc/cowrie.cfg.dist etc/cowrie.cfg
vim etc/cowrie.cfg

Minimal config:

1
2
3
4
5

[honeypot]
hostname = backup-server

[ssh]
listen_endpoints = tcp:2222:interface=0.0.0.0

Do not run Cowrie as root just to bind port 22. Keep Cowrie on a high port and forward traffic if needed.

systemd Unit

1
2
3
4
5
6
7
8
9
10
11
12
13
14

[Unit]
Description=Cowrie SSH Honeypot
After=network.target

[Service]
User=cowrie
Group=cowrie
WorkingDirectory=/home/cowrie/cowrie
ExecStart=/home/cowrie/cowrie/cowrie-env/bin/python /home/cowrie/cowrie/src/cowrie/start.py --nodaemon
Restart=always
RestartSec=5

[Install]
WantedBy=multi-user.target

Enable it:

1
2

sudo systemctl daemon-reload
sudo systemctl enable --now cowrie

Logs

1
2

journalctl -u cowrie -e --no-pager
sudo -iu cowrie tail -f ~/cowrie/var/log/cowrie/cowrie.json

The JSON log is usually the most useful file for later analysis.

Firewall Or Port Forwarding

If Cowrie listens on 2222, a simple redirect can expose it as port 22:

1
2
3
4
5
6

table ip nat {
    chain prerouting {
        type nat hook prerouting priority dstnat;
        tcp dport 22 redirect to :2222
    }
}

Only do this if the real SSH service is moved somewhere else, such as 22222.

Notes

• Do not reuse real hostnames, banners, usernames, or internal paths.
• Logs can contain malicious payloads. Treat them as untrusted input.
• Keep the honeypot isolated from important credentials and services.

SSL Certificate Renewal Notes

This note records a simple SSL certificate workflow with certbot: acquire, verify, renew, and deploy.

The example domain is api.example.com. Replace it with your own domain.

Acquire A Certificate

For a standalone HTTP-01 challenge, port 80 must be reachable and not occupied by another process:

1

sudo certbot certonly --standalone -d api.example.com

If Caddy or Nginx is already using port 80, stop it temporarily:

1
2
3

sudo systemctl stop caddy
sudo certbot certonly --standalone -d api.example.com
sudo systemctl start caddy

Check The Certificate

1
2
3
4

sudo certbot certificates
sudo openssl x509 \
  -in /etc/letsencrypt/live/api.example.com/fullchain.pem \
  -noout -dates

Enable Renewal

1
2

sudo systemctl enable --now certbot.timer
systemctl list-timers | grep certbot

Run a dry test:

1

sudo certbot renew --dry-run

Deploy Hook

Some services cannot read directly from /etc/letsencrypt/live/..., or they need certificate files copied into a service-owned directory.

Example hook for a service called myapp:

1
2
3
4
5
6
7
8
9
10
11

#!/usr/bin/env bash
set -euo pipefail

DOMAIN="api.example.com"
TARGET_DIR="/etc/myapp/cert"

install -d -m 0750 "$TARGET_DIR"
install -m 0644 "/etc/letsencrypt/live/$DOMAIN/fullchain.pem" "$TARGET_DIR/fullchain.pem"
install -m 0600 "/etc/letsencrypt/live/$DOMAIN/privkey.pem" "$TARGET_DIR/privkey.pem"

systemctl reload myapp

Install it as a deploy hook:

1
2

sudo install -m 0755 deploy-myapp-cert.sh \
  /etc/letsencrypt/renewal-hooks/deploy/myapp.sh

Xray Reality / VLESS Setup

This note records a minimal Xray Reality / VLESS setup.

The example values are fake but shaped like real values, so the config is easier to read than a wall of placeholders.

Example environment:

• server: vpn.example.com
• listen port: 443
• client UUID: 11111111-2222-4333-8444-555555555555
• Reality private key: example_private_key_do_not_use
• Reality public key: example_public_key_do_not_use
• Reality short id: a1b2c3d4e5f60708
• camouflage target: www.microsoft.com:443

Replace all of them.

Service Commands

Check the service:

1
2

sudo systemctl status xray
sudo journalctl -u xray -e --no-pager

After editing the config, test it before restart:

1
2

sudo xray run -test -config /usr/local/etc/xray/config.json
sudo systemctl restart xray

Generate IDs And Keys

1
2
3

xray uuid
xray x25519
openssl rand -hex 8

Keep the private key on the server. Put the public key in the client config.

Server Config Example

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33

{
  "inbounds": [
    {
      "listen": "0.0.0.0",
      "port": 443,
      "protocol": "vless",
      "settings": {
        "clients": [
          {
            "id": "11111111-2222-4333-8444-555555555555",
            "flow": "xtls-rprx-vision"
          }
        ],
        "decryption": "none"
      },
      "streamSettings": {
        "network": "tcp",
        "security": "reality",
        "realitySettings": {
          "show": false,
          "dest": "www.microsoft.com:443",
          "xver": 0,
          "serverNames": ["www.microsoft.com"],
          "privateKey": "example_private_key_do_not_use",
          "shortIds": ["a1b2c3d4e5f60708"]
        }
      }
    }
  ],
  "outbounds": [
    { "protocol": "freedom" }
  ]
}

Firewall

Only the public entry port needs to be open:

1

sudo nft add rule inet filter input tcp dport 443 accept

If SSH uses a custom port such as 22222, keep that rule separate and preferably source-restricted.

Client-Side Fields

A client profile usually needs:

1
2
3
4
5
6
7
8

address: vpn.example.com
port: 443
uuid: 11111111-2222-4333-8444-555555555555
flow: xtls-rprx-vision
security: reality
sni: www.microsoft.com
publicKey: example_public_key_do_not_use
shortId: a1b2c3d4e5f60708

Notes

• privateKey, UUID, and short id are secrets. Do not publish real values.
• Time sync matters. If the client and server clocks are too far apart, debugging becomes confusing.
• Start with a direct connection first. Add extra reverse proxies only after the base config works.

VPS nftables Firewall With Docker

This note records a small nftables firewall setup for a VPS that also runs Docker.

The goal is not to write a clever universal ruleset. The goal is simpler: keep the host input path small, expose only the ports that should be public, and avoid fighting Docker's own NAT rules.

The example uses documentation IP addresses:

• 203.0.113.10 as the admin's trusted IP
• 198.51.100.20 as the server IP
• 22222 as the SSH port

Replace them with your own values.

Basic Rules

Use the inet family so the same table can handle IPv4 and IPv6:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38

#!/usr/sbin/nft -f

flush ruleset

table inet filter {
    set trusted_ipv4 {
        type ipv4_addr
        flags interval
        elements = {
            203.0.113.10,
        }
    }

    chain input {
        type filter hook input priority filter; policy drop;

        iif "lo" accept
        ct state established,related accept
        ct state invalid drop

        ip protocol icmp accept
        ip6 nexthdr icmpv6 accept

        # SSH: only allow the trusted admin IP.
        ip saddr @trusted_ipv4 tcp dport 22222 accept

        # Public web entry.
        tcp dport { 80, 443 } accept
    }

    chain forward {
        type filter hook forward priority filter; policy accept;
    }

    chain output {
        type filter hook output priority filter; policy accept;
    }
}

Docker Notes

Docker manages its own forwarding and NAT rules. If you blindly flush everything and then set forward to drop, containers may lose network access or published ports may stop working.

For a small VPS, I usually keep the boundary simple:

• protect the host through the input chain
• let Docker manage container NAT
• expose public services through Caddy on 80/443
• bind internal app ports to 127.0.0.1 when possible

Example Docker port mapping:

1
2

ports:
  - "127.0.0.1:8080:8080"

Then let Caddy publish it over HTTPS.

Apply Safely

Validate before loading:

1

sudo nft -c -f /etc/nftables.conf

Protect SSH With Fail2ban

Public SSH servers are constantly scanned and brute-forced. Changing the SSH port is not real security by itself, but it reduces background noise. fail2ban adds an actual defensive layer by watching failed login attempts and temporarily banning abusive IP addresses.

This note records a minimal setup for SSH protection with fail2ban and systemd logs.

Install Fail2ban

Arch Linux:

1

sudo pacman -S fail2ban

Debian/Ubuntu:

1

sudo apt install fail2ban

Enable the service:

1

sudo systemctl enable --now fail2ban

Optional: Change SSH Port

Edit the SSH daemon config:

1

sudo vim /etc/ssh/sshd_config

Set a non-default port. This article uses 22222 as an example; replace it with your own value.

1

Port 22222

Before restarting SSH, keep your current SSH session open. A bad config or firewall mistake can lock you out.

Validate the config:

1

sudo sshd -t

Restart SSH:

1

sudo systemctl restart sshd

Some distributions use ssh instead of sshd as the service name:

1

sudo systemctl restart ssh

Test login from another terminal before closing the old session:

1

ssh -p 22222 user@example.com

Configure Fail2ban For SSH

Create a local jail config instead of editing the packaged defaults:

1

sudo vim /etc/fail2ban/jail.d/sshd.local

Minimal config:

1
2
3
4

[sshd]
enabled = true
port = 22222
backend = systemd

If you keep SSH on the default port, use:

1

port = ssh

Restart fail2ban:

1

sudo systemctl restart fail2ban

Check Status

List enabled jails:

1

sudo fail2ban-client status

Check the SSH jail:

1

sudo fail2ban-client status sshd

View logs:

1

sudo journalctl -u fail2ban -e

On systems where fail2ban logs to a file:

1

sudo less /var/log/fail2ban.log

Unban An IP

If you accidentally ban yourself, unban the IP from another trusted session:

1

sudo fail2ban-client set sshd unbanip 203.0.113.10

203.0.113.10 is a documentation example address. Replace it with the real IP you need to unban.

Safer SSH Baseline

Fail2ban is only one layer. These SSH settings are usually worth enabling too:

1
2
3

PermitRootLogin no
PasswordAuthentication no
PubkeyAuthentication yes

After changing SSH config, always validate and restart:

1
2

sudo sshd -t
sudo systemctl restart sshd

Notes

• Do not rely on port changes as the only protection.
• Prefer SSH keys over passwords.
• Keep an existing SSH session open while changing SSH and firewall settings.
• If a firewall is enabled, allow the SSH port before restarting SSH.
• Use /etc/fail2ban/jail.d/*.local files for local overrides so package updates do not overwrite your changes.

InspIRCd IRC Server With TLS

This note records a minimal InspIRCd configuration for running a small IRC server with TLS support. The example exposes a plain client port on 6667 and a TLS client port on 6697.

The TLS setup uses the ssl_gnutls module and certificate files stored under /etc/inspircd/cert/.

Requirements

Install InspIRCd and make sure the GnuTLS SSL module is available:

1

sudo pacman -S inspircd

On Debian/Ubuntu-style systems, the package name may differ:

1

sudo apt install inspircd

You also need a certificate and private key. For a public domain, use Let's Encrypt or another ACME client. The config below expects:

1
2

/etc/inspircd/cert/fullchain.pem
/etc/inspircd/cert/privkey.pem

TLS Configuration

Add or adapt the following server, module, TLS profile, bind, admin, class, type, and oper blocks in your InspIRCd config.

Do not publish a real oper password. Generate a strong password or use InspIRCd's password hashing support if available in your setup.

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43

<server
  name="irc.example.com"
  description="Example IRC Server"
  network="ExampleNet"
>

<module name="ssl_gnutls">

<sslprofile
  name="DefaultTLS"
  provider="gnutls"
  certfile="/etc/inspircd/cert/fullchain.pem"
  keyfile="/etc/inspircd/cert/privkey.pem"
>

<bind address="" port="6667" type="clients">
<bind address="" port="6697" type="clients" ssl="DefaultTLS">

<admin
  name="Example Admin"
  nick="ExampleAdmin"
  email="admin@example.com"
>

<class name="Class" commands="*" privs="*">
<type name="NetAdmin" classes="Class" modes="+s +c">

<oper
  name="admin"
  password="REPLACE_WITH_A_STRONG_PASSWORD_OR_HASH"
  host="*@*"
  type="NetAdmin"
>
</oper>

</type>
</class>
</admin>
</bind>
</bind>
</sslprofile>
</module>
</server>

Check The Config

Before restarting the service, run InspIRCd's config test if your package provides it:

1

sudo inspircd --configtest

If your package uses a different wrapper, check the service logs after restart:

1
2
3
4

systemctl restart inspircd
systemctl status inspircd
systemctl stop inspircd
journalctl -u inspircd -e

Connect

Plain IRC:

1
2
3

server: irc.example.com
port: 6667
TLS: off

TLS IRC:

1
2
3

server: irc.example.com
port: 6697
TLS: on

With WeeChat:

1
2

/server add examplenet irc.example.com/6697 -ssl
/connect examplenet

With irssi:

1

/connect -ssl irc.example.com 6697

Oper Login

After connecting as a normal user, authenticate as an IRC operator:

1

/OPER admin <password>

If login succeeds, the user receives the privileges from the configured NetAdmin type.

Notes

• Use port 6697 for TLS clients. This is the common IRC-over-TLS port.
• Keep 6667 only if you intentionally want to allow plaintext clients.
• Restrict host="*@*" for real deployments. A narrower host mask is safer.
• Avoid committing real passwords into blog posts, git repositories, or public config examples.
• Prefer hashed oper passwords if your InspIRCd version and modules support them.