Your cPanel server’s IP can change for reasons you don’t control. Common causes include a provider migration, DDoS mitigation, subnet renumbering, or adding a dedicated NIC.
The hard part is not assigning the new address. The hard part is limiting the blast radius so sites keep loading, DNS still resolves, and mail doesn’t start bouncing.
This cPanel IP change configuration tutorial walks you through a safe WHM/cPanel re-IP in 2026. It includes checks that prevent the usual breakage.
This guide assumes you manage the server (VPS or dedicated) and can schedule a short maintenance window.
If you’d rather hand off the operational work, managed VPS hosting from HostMyCode is built for changes like this. That includes planned cutovers, DNS verification, and a clear rollback path if something doesn’t line up.
Before you touch anything: decide what “IP change” means
On a cPanel server, “changing the IP” can mean a few different things. If you mix them up, you can split services across old and new addresses.
That’s when support tickets pile up.
- Main shared IP changes: most shared websites and core services move to the new address.
- Dedicated IPs for specific accounts: these may stay as-is or change too, depending on what your provider allocated.
- Nameserver IP changes: if this box runs ns1/ns2, you must update registrar glue records.
Define your scope before you start. If this server is authoritative DNS for hosted zones (typical with WHM DNS), include DNS in the cutover plan.
Don’t leave DNS as a follow-up task.
cPanel IP change configuration tutorial: pre-flight checklist (15 minutes that saves hours)
Run these checks before you request the change or reboot into it. You’re inventorying what must be updated.
You’re also setting yourself up for a fast rollback.
- Confirm your current IPs:
hostname -f ip -br a curl -4s ifconfig.me - Record the current cPanel IP mapping:
/usr/local/cpanel/bin/whmapi1 listips --output=json | head - Export a list of dedicated-IP accounts:
/usr/local/cpanel/bin/whmapi1 listaccts searchtype=ip search="" | grep -E 'user:|ip:' - Check whether the server is a nameserver (ns1/ns2 on this host):
grep -R "^nameserver" -n /etc/wwwacct.conf - Lower DNS TTLs ahead of time (recommended): set A records to 300 seconds for key zones at least a few hours before cutover.
- Snapshot/backup: at minimum, take a VM snapshot or do a quick config backup of /etc and key cPanel files.
tar -czf /root/pre-reip-etc.tgz /etc /var/named /usr/local/cpanel/etc 2>/dev/null
If you want a disciplined DNS cutover workflow (TTL planning, record validation, and rollback), keep this runbook close: DNS cutover tutorial.
Step 1 — Add the new IP at the OS level (network config)
How you apply the new address depends on your distro and how your provider assigns IPs. In practice, you’ll usually follow one of these patterns:
- Replace primary IP (old removed, new becomes main).
- Add new IP as an alias (both live briefly, then old removed after validation).
Your provider should supply the new IPv4, gateway, and netmask/CIDR. Apply it using the supported method for your OS.
Examples include Netplan on Ubuntu, NetworkManager on AlmaLinux/Rocky, or provider tooling.
Then verify routing and outbound connectivity:
ip -4 route
ping -c 3 1.1.1.1
curl -4s ifconfig.me
Tip: If your provider can keep the old IP routed for a few hours, take the overlap. It lets you validate live traffic on the new IP.
It also gives you a calmer rollback option.
Step 2 — Tell cPanel/WHM about the new main shared IP
Once the OS routes the new IP, update WHM so cPanel uses it for shared hosting, core services, and new accounts.
- Log in to WHM as root.
- Go to IP Functions → Change Site’s IP Address for single accounts, or use the bulk change tool for shared IP migration (exact menu labels may vary slightly by build).
- For the server-level shared IP, use IP Functions → Change Main IP Address (WHM will update internal references).
CLI alternative (useful on headless/admin-only boxes):
/usr/local/cpanel/bin/set_hostname $(hostname -f)
/usr/local/cpanel/scripts/mainipchange --help
Important: Script behavior and flags vary across cPanel builds. In 2026, confirm what’s available under /usr/local/cpanel/scripts/ before you rely on it.
If you’re unsure, use WHM. WHM usually updates more references than manual edits.
Step 3 — Update Apache/Nginx bindings (and any reverse proxy)
On a standard WHM Apache stack, cPanel regenerates most vhost configs for you. Still, confirm each service is listening on the address you expect.
- Apache:
/etc/apache2/(Debian/Ubuntu) or/etc/httpd/(RHEL-family) - Nginx (if you use it as a reverse proxy):
/etc/nginx/nginx.confand site snippets
Quick checks:
ss -lntp | grep -E ':(80|443)\s'
/usr/local/cpanel/scripts/rebuildhttpdconf
/usr/local/cpanel/scripts/restartsrv_httpd
If Nginx sits in front of Apache/cPanel, recheck your proxy headers and SSL routing. Losing the real client IP is a common post-change surprise.
Misrouted SNI is another.
Reference: Nginx reverse proxy setup guide.
Step 4 — DNS: update A records, nameserver glue, and WHM zone templates
Most “IP change” incidents are really DNS incidents. The server can be healthy, but users will still hit the old IP until the right records move.
After that, resolvers still need time to refresh those records.
4.1 Update A records for hosted domains
If this server hosts DNS zones (BIND/named), update any A records that still point at the old IP. The usual suspects are:
@/ root A recordwwwA recordmailA record (if mail lives here)
On cPanel, zones typically live in /var/named/. After edits, increment the serial and reload:
rndc reload
4.2 If you use ns1/ns2 on this server: update glue records
If your nameservers (ns1.example.com / ns2.example.com) still resolve to the old IP, update glue at the registrar. Without this, some resolvers keep querying the old address.
That can happen even after you fix the zone files.
If you want a dedicated runbook for registrar glue plus WHM nameserver alignment, use: cPanel nameserver setup guide. (Don’t skip the glue step.)
4.3 Update WHM’s default zone templates (so new domains don’t inherit the old IP)
WHM generates new zones from templates. If those templates still contain the old IP, the next domain you add can publish broken DNS.
In WHM, review the DNS zone templates. Replace any hard-coded A record IPs with the new shared IP.
Step 5 — Email continuity: PTR/rDNS, HELO, SPF/DKIM/DMARC alignment
An IP change can turn “mail is fine” into “everything is spam” fast. The fixes are usually straightforward.
They just need to happen immediately.
5.1 Set reverse DNS (PTR) for the new IP
PTR should match a hostname that forward-resolves back to the same IP. Example: server1.yourdomain.com → A record → new IP, and PTR new IP → server1.yourdomain.com.
Follow the HostMyCode runbook for PTR changes: rDNS setup guide tutorial.
5.2 Update SPF for domains that send mail from this server
If SPF records reference the old IP, replace it with the new one. Example:
v=spf1 ip4:NEW.IP.ADDR include:your-relay.example ~all
5.3 Recheck DKIM/DMARC and SMTP banners
- DKIM keys don’t change because of the IP, but confirm DNS is correct and you don’t have split-brain zones.
- DMARC policy can stay the same, but watch for alignment failures right after the cutover.
- Confirm your server’s hostname resolves to the new IP (A record).
After the change, confirm Exim is presenting the identity you expect:
exim -bV | head
hostname -f
If you want one checklist for SPF/DKIM/DMARC plus PTR, this guide keeps it organized: email authentication setup guide.
Step 6 — SSL and AutoSSL: verify the right virtual hosts and DCV checks
Most TLS issues after an IP change come from two causes:
- DNS still points some users to the old IP.
- AutoSSL/DCV validation hits the wrong endpoint during the overlap period.
Checklist:
- Confirm each key hostname resolves publicly to the new IP:
dig +short A example.com - Confirm the server returns the expected certificate on the new IP:
openssl s_client -connect example.com:443 -servername example.com - Run AutoSSL checks after DNS settles, not while resolvers disagree.
If renewal fails or you see broken chains after the move, this walkthrough is the fastest way back to green: cPanel AutoSSL troubleshooting tutorial.
Step 7 — Firewall and security groups: open the new IP path
If your provider uses external firewalls (security groups), make sure rules still match the new address. Do the same if you run CSF/iptables locally.
Also confirm the interface layout did not change during the renumber.
Quick diagnostics:
csf -l | head
iptables -S | head
ss -lntup
If you need a safe baseline that won’t lock you out mid-change, use: cPanel CSF firewall setup tutorial.
Step 8 — Validate services end-to-end (web, DNS, mail) with a tight runbook
Don’t stop at “the homepage loads.” Quiet failures often show up later.
Watch webhook endpoints, API hostnames, mail reputation, and stale DNS.
Web checks
- Test a few domains over HTTP and HTTPS.
- Confirm redirects and canonical hostnames behave as expected.
- Verify the server sees the right client IP (especially behind a proxy/CDN).
curl -I http://example.com
curl -I https://example.com
DNS checks
- Confirm authoritative answers from your nameserver (if applicable).
- Confirm public resolvers return the new IP.
dig @1.1.1.1 example.com A +short
dig ns1.example.com example.com SOA
Mail checks
- Check inbound MX targets still point where you expect.
- Send a test outbound email to a mailbox you control and confirm headers show the new sending IP.
dig example.com MX +short
exim -bp | head
Common failure modes (and how to fix them fast)
Sites work for you, but customers still hit the old server
- DNS TTL wasn’t lowered early enough.
- Extra A records (www, api, static) still point to the old IP.
- Your CDN/origin config still references the old address.
Fix: query multiple resolvers with dig. Then update every hostname that should move, not just the root domain.
AutoSSL fails after IP change
- DCV checks land on the old IP due to partial propagation.
- HTTP-01 validation is blocked by firewall rules or a proxy route.
Fix: wait for DNS to converge. Confirm port 80 hits the correct vhost, then rerun AutoSSL.
Email starts bouncing or landing in spam
- PTR/rDNS isn’t set (or doesn’t match the hostname).
- SPF still lists the old IP.
- Hostname A record points to the old IP, creating a forward/reverse mismatch.
Fix: set PTR first. Then correct the hostname A record and SPF. Retest after propagation.
Post-change hardening: reduce risk for the next cutover
Once the dust settles, do a little cleanup. It makes the next renumber routine.
- Set DNS TTLs back to normal (e.g., 3600–14400) for stability and lower resolver load.
- Document the new IP mapping and the dedicated-IP account list.
- Confirm backups still write off-host and that restore points exist.
If you want a restore-first approach (not just “backups enabled”), keep a verified restore runbook. This pairs well: VPS backup restore tutorial.
Summary: the safe re-IP path in 2026
- Prepare: inventory IPs, dedicated accounts, nameserver status, and DNS TTLs.
- Apply the new IP at the OS level, ideally with a short overlap window.
- Update the WHM main IP and rebuild/restart web services.
- Fix DNS (A records, zone templates, glue if needed) and verify using public resolvers.
- Protect mail reputation: set PTR, update SPF, and confirm hostname alignment.
- Run end-to-end checks and keep rollback options open until everything stabilizes.
If your IP renumber is part of a larger move (new VPS, new region, or hardware refresh), HostMyCode can help you cut over cleanly. You can do it on a self-managed HostMyCode VPS or with a supported plan on managed VPS hosting.
If your WHM server needs an IP change for a migration, keep it boring: stage the cutover, validate DNS from multiple resolvers, and confirm mail identity before you send volume again. HostMyCode offers VPS and managed VPS hosting plans that fit cPanel workloads, with less guesswork during the maintenance window.
FAQ
Can I keep the old IP and new IP active at the same time?
Often, yes—if your provider allows it. A short overlap window gives you time to validate services and keeps downtime low while DNS propagates.
Do I need to reissue SSL certificates after a cPanel IP change?
Usually no. Certificates are tied to hostnames, not IPs. The most common problem is DNS still pointing to the old IP, which causes AutoSSL validation to fail.
What’s the quickest way to confirm DNS has switched globally?
Query multiple public resolvers and compare results: dig @1.1.1.1, dig @8.8.8.8, and your ISP resolver. When they all return the new A record, you’re close.
Why did email deliverability drop after the IP change?
A new IP without PTR, or SPF still listing the old IP, will trigger authentication and reputation problems. Set rDNS/PTR first, then fix SPF and hostname alignment.
Should I change nameserver glue records for every domain?
Only for domains that delegate to nameservers hosted on this server (ns1/ns2 using your IP). If you use third-party DNS, you won’t touch glue.