Frequently Asked Questions

dix.su is a platform with a set of tools for working online without a server with a public IP:

• Proxy tunnel — publishes a local service at slug.dix.su
• Personal profile card — a page with your links and social accounts
• Short links — with proven authorship and click statistics
• Reviews (Otzovik) — reviews from verified users only
• Catalog — public directory of user services

All core features are free. Paid plans unlock direct TCP connections (SSH, RDP, databases), visit analytics, and private E2E mode.

Yes. The SIMPLE plan is free with no time limit: HTTP tunnel, 10 GB/month, profile card, short links, catalog, and a 14-day private mode trial.

Paid plans (VIP/PRO/PERS) add more traffic, direct TCP connections (SSH, RDP, VNC, databases), visit analytics, and full private E2E mode.

That's exactly what the platform is built for. CGNAT (carrier-grade NAT) — where an ISP shares one public IP among hundreds of customers — completely blocks inbound connections.

device_client makes an outbound encrypted WebSocket connection to the proxy server, through which all traffic flows. No public IP, no port forwarding, no router changes needed.

For HTTP tunnels (websites, web apps, APIs) — minimal: download a binary, run one command in the terminal. For TCP tunnels (SSH, databases) — basic command-line familiarity.

If you'd rather not install anything — get a ready-made device from the shop: plug it in and the tunnel starts automatically.

Traffic is always encrypted between the visitor's browser and our proxy (TLS). In standard mode TLS terminates at the proxy — the server can technically see decrypted traffic, but does not store its contents.

For full confidentiality (PERS plan) the E2E mode is available: a Let's Encrypt certificate is issued directly to your device via DNS-01; the proxy relays encrypted bytes without decrypting them. The private key never leaves your device.

Supported: Linux (x86_64, ARM64 — including Raspberry Pi), macOS (Apple Silicon and Intel), Windows (x86_64). A self-contained binary with an embedded Erlang runtime — nothing extra to install.

Ready-made devices from the shop come pre-configured and auto-start on boot.

The tunnel becomes unavailable immediately — visitors see an "device offline" page. When the device comes back online, device_client reconnects automatically with exponential back-off. No action required from you.

Via systemd (Linux): create /etc/systemd/system/dixsu.service:

[Unit]
Description=dix.su tunnel
After=network-online.target

[Service]
ExecStart=/usr/local/bin/device_client your-slug your-token 8080
Restart=always
RestartSec=5

[Install]
WantedBy=multi-user.target

Then run: systemctl enable --now dixsu

Via Docker Compose: add restart: unless-stopped to the device_client service block.

Yes. The GitLab catalog has ready-made stacks (dixsu-test, dixsu-mysql, etc.) that launch both your service and the tunnel with one command:

git clone https://gitlab.com/dixsu/market/dixsu-test
# fill in .env: DIXSU_SLUG and DIXSU_TOKEN
sh setup.sh

In 10–15 seconds your service is live at https://slug.dix.su. Free, no trial.

Yes, from the VIP plan upward. The platform automatically issues a TLS certificate via Let's Encrypt. Steps:

1. Add a CNAME pointing to your-slug.dix.su and a TXT record for ownership verification in your domain's DNS
2. In your dashboard (Tunnel → Custom Domain), enter the domain and click Connect
3. After DNS and attribution checks pass, the certificate is issued automatically (usually 1–5 minutes)
4. Visitors immediately see your domain and a valid padlock

Both APEX domains (example.com) and subdomains (shop.example.com) are supported.

You need two records:

TXT host nuance: most registrars (Namecheap, GoDaddy, reg.ru) expect a relative host — enter just _dixsu and they append the domain automatically. Cloudflare and some panels require the full name: _dixsu.mysite.com. If you enter the FQDN at a registrar that also appends the domain, you'll end up with _dixsu.mysite.com.mysite.com — that won't verify.

DNS changes propagate in 5 minutes to 48 hours (usually 5–30 minutes).

Before issuing the SSL certificate, the platform automatically checks that your site's HTML contains a link to https://dix.su or https://www.dix.su. This is a small attribution requirement for using the free tunnel infrastructure.

If the link is already on your site, this step passes automatically with no action needed.

Each account can connect one custom domain. Change limits:

These limits protect against Let's Encrypt certificate rate limits, which cap issuance per domain per day.

Check step by step:

1. CNAME not yet propagated — run dig CNAME mysite.com +short. It should return your-slug.dix.su. If empty — wait a bit longer.
2. SSL certificate still being issued — the agent processes the queue every 60 seconds. Check the dashboard: the domain status should show "active". If it still says "pending" — wait a minute.
3. Device is offline — make sure device_client is running and the tunnel is reachable at your-slug.dix.su.
4. Browser certificate error — try incognito mode or clear the SSL cache. Browsers sometimes cache an old certificate.

SSH tunnel requires the VIP plan. SNI routing needs the slug sent before the SSH handshake begins. Connect via:

ssh -o ProxyCommand='{ echo DIXSU:your-slug; cat; } | nc your-slug.dix.su 2222' user@localhost

Add to ~/.ssh/config for convenience:

Host my-server
    HostName localhost
    User ubuntu
    Port 2222
    ProxyCommand { echo DIXSU:your-slug; cat; } | nc your-slug.dix.su 2222

Then just run ssh my-server. SCP, SFTP, and SSH port-forwarding (-L, -R) also work through this tunnel.

Windows 10 and 11 include OpenSSH — no separate installation needed. The config file lives at %USERPROFILE%\.ssh\config (e.g. C:\Users\John\.ssh\config).

The challenge: nc is not installed on Windows by default. For ProxyCommand you have a few options:

Option 1 — WSL (recommended): if WSL 2 with Ubuntu is installed, ProxyCommand works through it:

# %USERPROFILE%\.ssh\config
Host your-slug.dix.su
    Port 2222
    ProxyCommand wsl.exe bash -c "{ echo DIXSU:your-slug; cat; } | nc your-slug.dix.su 2222"

Option 2 — Git for Windows: Git Bash includes bash.exe and nc. Specify the full path in config:

Host your-slug.dix.su
    Port 2222
    ProxyCommand "C:/Program Files/Git/usr/bin/bash.exe" -c "{ echo DIXSU:your-slug; cat; } | nc your-slug.dix.su 2222"

Option 3 — PuTTY: in Connection → Proxy → Proxy type: Local, and in «Telnet command / Local proxy command»:

cmd /c "echo DIXSU:your-slug & type - | nc your-slug.dix.su 2222"

SFTP is an SSH subsystem running over the same tunnel port 2222. Requires the VIP+ plan.

Command line (Linux / macOS / Windows with WSL):

sftp -P 2222 \
  -o "ProxyCommand=bash -c '{ echo DIXSU:your-slug; cat; } | nc your-slug.dix.su 2222'" \
  user@your-slug.dix.su

If you already have a ~/.ssh/config block for your slug, simply run sftp user@your-slug.dix.su.

FileZilla (Linux / macOS / Windows):

• Protocol: SFTP
• Host: your-slug.dix.su, Port: 2222
• Auth: password or key (Edit → Settings → Connection → SFTP, add your key)

WinSCP (Windows):

• Protocol: SFTP, Host: your-slug.dix.su, Port: 2222
• Advanced → Connection → Proxy → Proxy type: Local
• Proxy command: wsl.exe bash -c "{ echo DIXSU:your-slug; cat; } | nc your-slug.dix.su 2222"

Krusader / Dolphin (Linux KDE): add a block to ~/.ssh/config (see the SSH question), then type sftp://user@your-slug.dix.su/ in the address bar.

The technology is called SSHFS — it mounts folders from your remote device over the SSH tunnel as a regular directory or drive. Requires VIP+, no extra ports needed.

Linux (Debian / Ubuntu / Raspberry Pi OS):

sudo apt install sshfs
mkdir -p ~/mnt/dixsu
sshfs user@your-slug.dix.su:/home/user ~/mnt/dixsu \
  -p 2222 \
  -o ProxyCommand="bash -c '{ echo DIXSU:your-slug; cat; } | nc your-slug.dix.su 2222'" \
  -o reconnect,ServerAliveInterval=15

# Unmount:
fusermount -u ~/mnt/dixsu

macOS:

# Requires macFUSE + sshfs via Homebrew:
brew install --cask macfuse
brew install sshfs

sshfs user@your-slug.dix.su:/home/user ~/mnt/dixsu \
  -p 2222 \
  -o ProxyCommand="bash -c '{ echo DIXSU:your-slug; cat; } | nc your-slug.dix.su 2222'"

# Unmount:
umount ~/mnt/dixsu

Windows — SSHFS-Win (WinFsp):

• Install WinFsp and SSHFS-Win
• In Explorer: right-click «This PC» → «Map network drive»
• Folder: \\sshfs.r\user@your-slug.dix.su!2222

Or from the command line:

net use X: \\sshfs.r\user@your-slug.dix.su!2222

Yes, without root. True SSHFS filesystem mounting on Android requires root, but browsing and copying files over SFTP does not.

Working setup: Termux + Material Files

Step 1 — in Termux, create a local SSH tunnel:

pkg install openssh

# ~/.ssh/config
Host your-slug.dix.su
    Port 2222
    ProxyCommand bash -c '{ echo DIXSU:your-slug; cat; } | nc your-slug.dix.su 2222'

# Start the tunnel (keep it running):
ssh -N -L 127.0.0.1:10022:127.0.0.1:22 user@your-slug.dix.su

Step 2 — in CIFS Documents Provider or Material Files, add an SFTP connection: host 127.0.0.1, port 10022, device login and password.

Files appear immediately in the Android system file picker — visible to all apps (open a video in VLC, a document in an office app, etc.). No root required.

There is no direct TCP port for SMB — the protocol carries no TLS header the proxy can use to identify the target device. However, SMB works perfectly via an SSH tunnel with port forwarding (-L). Requires the VIP+ plan.

Step 1 — create the tunnel (keep open in a separate terminal):

ssh -p 2222 \
  -o "ProxyCommand=bash -c '{ echo DIXSU:your-slug; cat; } | nc your-slug.dix.su 2222'" \
  -L 127.0.0.1:1445:127.0.0.1:445 -N user@your-slug.dix.su

The device's SMB is now reachable locally at localhost:1445.

Linux — mount:

sudo apt install cifs-utils
mkdir -p ~/mnt/smb
sudo mount -t cifs //127.0.0.1/share ~/mnt/smb \
  -o port=1445,username=samba-user,password=samba-pass

# Unmount:
sudo umount ~/mnt/smb

Or browse without mounting:

smbclient //127.0.0.1/share -p 1445 -U samba-user

macOS — Finder: Go → Connect to Server → smb://127.0.0.1:1445/share. Enter Samba credentials.

Windows — via WSL:

# SSH tunnel in WSL (step 1), then mount:
sudo mkdir -p /mnt/smb
sudo mount -t cifs //127.0.0.1/share /mnt/smb \
  -o port=1445,username=samba-user,password=samba-pass,vers=3.0

RDP uses direct TCP port 3389 with TLS/SNI routing — requires the PRO+ plan. No ProxyCommand needed: the client connects directly to your-slug.dix.su:3389.

On the device: standard xrdp (Linux) or enabled Remote Desktop (Windows) — no extra TLS configuration, the proxy handles routing.

Windows (built-in mstsc):

# Run in Win+R or PowerShell:
mstsc /v:your-slug.dix.su:3389

Or: «Remote Desktop Connection» → Computer: your-slug.dix.su:3389.

Linux (Remmina): Protocol RDP, server your-slug.dix.su, port 3389, security TLS or Negotiate. Accept the xrdp self-signed certificate on first connection.

macOS (Microsoft Remote Desktop): «Add PC» → PC name: your-slug.dix.su:3389.

Via SSH tunnel (VIP plan, no PRO):

# Step 1 — keep this terminal open:
ssh -p 2222 \
  -o "ProxyCommand=bash -c '{ echo DIXSU:your-slug; cat; } | nc your-slug.dix.su 2222'" \
  -L 13389:localhost:3389 -N user@your-slug.dix.su

# Step 2 — connect to localhost in another terminal / app:
mstsc /v:localhost:13389            # Windows
xfreerdp /v:localhost:13389 /u:user # Linux

VNC uses port 4900 — requires the PRO+ plan. Unlike RDP, TLS on the device is mandatory: run x11vnc with the --ssl flag.

# On the device — generate a key and start with SSL:
mkdir -p ~/.vnc/ssl
openssl req -new -x509 -days 365 -nodes \
  -out ~/.vnc/ssl/vnc.crt -keyout ~/.vnc/ssl/vnc.key -subj "/CN=vnc-tunnel"
x11vnc -display :0 -forever -nopw \
  -ssl ~/.vnc/ssl/vnc.key,~/.vnc/ssl/vnc.crt -rfbport 5900

Linux (TigerVNC / vncviewer):

vncviewer your-slug.dix.su:4900

Linux (Remmina): Protocol VNC, server your-slug.dix.su, port 4900, enable SSL/TLS.

Windows: RealVNC Viewer, TigerVNC Viewer, or UltraVNC — server your-slug.dix.su::4900 (double colon for non-default port), enable encryption.

macOS: Finder → Go → Connect to Server → vnc://your-slug.dix.su:4900, or RealVNC Viewer.

Alternative via SSH tunnel (no x11vnc --ssl, VIP plan):

# Step 1 — keep this terminal open:
ssh -p 2222 \
  -o "ProxyCommand=bash -c '{ echo DIXSU:your-slug; cat; } | nc your-slug.dix.su 2222'" \
  -L 15900:localhost:5900 -N user@your-slug.dix.su

# Step 2 — connect your VNC client to the local port:
vncviewer localhost:15900   # Linux
# Windows / macOS: set the server to localhost:15900 in any VNC client

The proxy routes connections by reading the SNI field from the first TLS packet. TLS must be initiated by the client before the application protocol starts.

RDP adds CredSSP/TLS over its first packet automatically — SNI arrives at the proxy as expected.

VNC (RFB protocol) opens with a server greeting with no TLS, so the proxy receives the first bytes without SNI and can't route. Solution: run x11vnc --ssl so TLS is server-initiated at the very first byte, and SNI reaches the proxy correctly.

A standard tunnel (slug.dix.su) is publicly accessible — just share the link.

To restrict access, enable private mode (PERS plan): the tunnel requires a dix.su account login, everyone else sees a placeholder page.

The SIMPLE plan includes a 14-day free trial of private mode — try it at no cost.

The proxy received a connection but device_client with your slug isn't currently connected. Checklist:

• Is device_client running? Check with ps aux | grep device_client
• Are the slug and token in the startup command correct?
• Does your device have internet access?
• For TCP protocols: is the required port enabled in your dashboard (Direct connections section)?
• Does your plan support the requested protocol?

HTTP tunnel — usually yes. The client connects over WSS (WebSocket Secure) — essentially HTTPS on port 443, which is allowed in most corporate networks.

TCP tunnels (SSH, RDP, databases) use non-standard ports (2222, 3389, 4432, etc.). If those are blocked by a corporate firewall, TCP tunnels won't be reachable.

The profile card is a public page at dix.su/p/your-slug — a Linktree-style page on the dix.su domain, free and with identity verification.

It displays: avatar, name, biography, link buttons (website, portfolio, shop, docs) and social media icons. Free for all users. Editing is done inline — no page reloads needed.

Available social icons: Telegram, GitHub, VK, Instagram, YouTube, LinkedIn, WhatsApp, and more — added in one click from profile settings.

In addition to social icons, you can add any number of custom link buttons pointing to any URL. Button order is set by drag-and-drop.

Your dashboard shows a click counter next to each button. Data accumulates automatically — no third-party analytics services required.

The key difference is proven authorship. Each link of the form dix.su/abc1234 is tied to a specific dix.su account. Anyone can verify who created it at link.dix.su.

This solves the trust problem: receiving a link, you can verify it was created by a real person with a verified profile — not an anonymous sender.

Also: links never expire, there's no quantity limit, and 7-character codes are guaranteed collision-free.

Go to link.dix.su and paste the link. For dix.su links you'll see: creator's name and avatar, creation date, click count, and the final destination URL.

For external links (from other shorteners) — the service shows the full HTTP redirect chain to the final address. Anonymous links are clearly marked as such.

No. Create as many as you need, links never expire. Click counters for each link are visible in your dashboard.

The verification tool at /clarity lets you find out who is behind a link or tunnel before you visit it.

• Links — paste dix.su/abc1234 or any URL to learn the author and final destination
• Tunnels — enter an address (eskimos.dix.su) or just the slug to learn the owner and their verification level

The idea: before opening an unfamiliar link or tunnel, confirm there's a real, verified person behind it.

When verifying a tunnel or link, you see how many social platforms (GitHub, VK, Telegram, Yandex, etc.) are linked to the owner's account.

More verified platforms = higher objective trust level. An account with GitHub, VK, and Telegram is much harder to create anonymously than one with email only.

Otzovik is a review platform for any internet resources: dix.su tunnels, websites, SaaS services, online shops, mobile apps. Only verified dix.su users can leave reviews — no anonymous reviews.

You can leave a star rating, pros and cons. Every review is permanently tied to a specific account — you always see who wrote it and how verified they are.

Every review is hard-linked to a dix.su account. To leave a review you need to register and verify at least one social platform (GitHub, VK, Telegram, etc.).

Creating a batch of fake accounts with real social media is technically non-trivial — each account's linked social profiles are visible upon inspection. Reviews from highly verified accounts carry more weight.

• Create a dix.su account and link at least one social platform
• Go to Otzovik, find the resource or add it yourself
• Leave an honest review with a rating, pros, and cons

The catalog is a public directory of active dix.su tunnels open for public viewing. Listing is free and helps attract an audience among platform users.

To add your project: in your dashboard open "Tunnel → Catalog" and fill in a description and category. The catalog supports sorting by Otzovik rating.

Anything running on your device that accepts network connections:

• Personal sites, blogs, portfolios (Nginx, WordPress, Ghost, Hugo)
• Media servers: Jellyfin, Plex, Navidrome
• File storage: Nextcloud, Seafile
• Smart home: Home Assistant, openHAB, Zigbee2MQTT, Frigate
• Git servers: Gitea, Forgejo
• Messaging: Matrix/Element, Mattermost
• Monitoring: Grafana, Uptime Kuma
• Password managers: Vaultwarden
• Databases: PostgreSQL, MySQL, Redis, MongoDB (via TCP tunnel, PERS plan)
• Dev environments, CI agents, demo servers for clients

Full list of permitted use cases — in the Acceptable Use Policy.

Bedrock Edition (port 19132) uses UDP. dix.su works over WebSocket → TCP; UDP datagrams are not transmitted at all.

Java Edition (port 25565) uses plain TCP without TLS. Platform routing is based on TLS SNI: the proxy identifies the destination device by reading SNI from the TLS ClientHello. Minecraft clients don't speak TLS → the proxy can't determine the destination → connection is rejected.

This is an architectural constraint, not a temporary bug.

What does work for gaming: web-based game server panels (Pterodactyl, AMP, etc.) work perfectly through a regular HTTP tunnel.

No. The platform's relay mechanism runs over TCP; UDP datagrams are not transmitted.

Affected: game servers using UDP, VoIP/SIP, STUN/TURN, QUIC, WireGuard, some P2P protocols.

Seven protocols on fixed ports:

All TCP connections arrive at one public IP. To determine which device to route to, the proxy reads the SNI field from the TLS ClientHello — it contains slug.dix.su, which uniquely identifies the tunnel.

Without TLS from the client, SNI is absent → routing is impossible. That's why sslmode=require for PostgreSQL, --ssl-mode=REQUIRED for MySQL, and --tls for Redis are not optional — they're required for the connection to work at all.

Each higher plan includes all features of the plans below it. Payment via T-Bank / Tinkoff (Russia) or international card.

All purchased plans are stored in your personal pool. One is active (running right now), the rest are frozen (days not counting down). You can switch between them instantly and without limits.

Example: you have VIP (20 days, active) and PRO (30 days, frozen). Need database access for the weekend — switch to PRO. Switch back to VIP on Monday — PRO still has 28 days, VIP still has 20. Nothing lost.

Switching is instant: the active plan freezes (days stop counting), and the selected frozen plan becomes active. Saved days are preserved exactly — no rounding, no losses. You can switch multiple times a day if needed.

A maximum of 1 day per plan per calendar day — regardless of how many times you switch. The system records the last deduction date and never charges the same plan twice on the same day.

Example: you switch between VIP and PRO 5 times in one day. Total: 1 day from VIP + 1 day from PRO = exactly 2 days total.

The system automatically activates the next frozen plan from your pool. You'll receive an email notification. If there are no frozen plans, the account falls back to free SIMPLE: the tunnel keeps working, but TCP access and analytics become unavailable until the next purchase.

Bottom line: your service won't go down the night a plan expires, as long as you have spare paid plans in your pool.

If you exhaust your monthly traffic quota, the system freezes your tunnel until the 1st of the next month. During the freeze, the paid-days counter stops. On the 1st the quota resets, the tunnel unfreezes automatically, and billing resumes from where it left off.

Yes — buying the same plan again adds 30 days to your current balance. The counter is not reset, days don't expire, there's no "buy before it runs out" pressure.

Example: you have 5 days of PRO left. Buy 30 more — now you have 35 days. Renew early without any risk of losing days.

The tunnel is automatically frozen until the 1st of the next month — the 10 GB quota resets monthly. Upgrade to a paid plan at any time and the tunnel unfreezes immediately.

Allowed: personal services, development, testing, business infrastructure, media, smart home, file storage, backup endpoints — any lawful personal or work use.

Prohibited (immediate account termination):

• Child sexual abuse material
• Terrorism and extremism content
• Sale of drugs, weapons, or forged documents
• Phishing and fraudulent schemes
• Distribution of malware, C2 servers
• DDoS attacks, unauthorized network scanning

Full text — in the Acceptable Use Policy. Reports: abuse@dix.su.

In a standard tunnel, TLS terminates at the dix.su proxy — the server sees decrypted traffic, though it does not store it.

In E2E mode (PERS plan), a Let's Encrypt certificate is issued directly to your device via DNS-01. The TLS handshake happens between the visitor's browser and your hardware; the proxy forwards the encrypted bytes without decrypting them. The private key never leaves your device.

The platform collects metadata: timestamp, IP address, traffic volume — for billing and abuse prevention. The content of traffic is not stored.

In E2E mode, content is technically inaccessible even to us — traffic is decrypted only on your device.

Write to abuse@dix.su immediately describing the situation. An admin will temporarily block the tunnel pending investigation.

In parallel: stop device_client on the device, rotate your access token in the dashboard, and check whether your service configuration has been altered.

Open the dashboard → Account tab and click "Delete account". You will be asked to confirm your email address.

After confirmation, your account is marked for deletion: your profile, business card, short links, and tunnel are immediately hidden from other users. No data is permanently deleted at this point — you have 30 days to change your mind.

After 30 days all data is permanently and irreversibly deleted. You will receive a farewell email with a restore button as soon as the deletion is requested.

The following are hidden immediately:

• Your public profile and business card
• All short links (dix.su/xxx)
• Tunnel token — the device_client connection is dropped
• Your catalog entry, if any
• Linked OAuth accounts (Google, GitHub, VK, etc.)

Email notifications are disabled automatically. Logging in is not possible during this period, but restoring the account is.

Permanent deletion of all records from the database occurs exactly 30 days after the request.

Three ways:

1. From the farewell email — click the "Restore account" button. It takes you straight to the restore page with your email pre-filled.
2. Directly — go to dix.su/account/restore, enter your email, and follow the instructions.
3. Via OAuth (Google, GitHub, VK, etc.) — simply sign in with any previously linked social account. The account is restored automatically.

After restoration all your data returns as it was: profile, links, tunnel settings. You will receive a confirmation email. Email notifications are re-enabled automatically.

All emails fall into two categories:

Transactional — cannot be disabled; they keep your account secure and functional:

• One-time password for login
• Email verification code when changing your email address
• Notification when a new login method (OAuth) is linked
• Account deletion notice and restoration confirmation
• device_client connection credentials
• Tax receipt (NPD) after payment
• Tunnel address (slug) change notice

Notifications — optional, can be disabled per category:

• Tunnel status — tunnel went offline or the web server stopped responding
• Suspicious activity — an attack on your tunnel was detected and blocked (VIP+ plans)
• Traffic limits — 80% of the monthly quota used, or tunnel frozen due to quota exhaustion
• Catalog & profile — catalog application approved/rejected, profile complaint received

There are two ways:

1. In your dashboard → "Notifications" tab — toggle the categories you want and click "Save". Settings take effect immediately.

2. One-click from any email — every notification email includes an "Unsubscribe from notifications" link in the footer. Clicking it instantly disables that category — no login required.

After unsubscribing you land on a confirmation page where you can re-enable the subscription if needed.

Repeat notifications for the same event are sent no more than once every 30 minutes. This prevents an email flood when a device has an unstable connection.

Traffic usage warnings (80%+) are sent at most once per day.

Transactional emails (login codes, email changes, account security) are not affected by notification settings and cannot be disabled — they are required for account functionality.

If you are still receiving notification emails after opting out, check whether you unsubscribed from the correct category. Your current settings are visible on the Notifications page. If the problem persists, contact support@dix.su.