The most realistic issue during the ICP filing process is: the website still needs development and testing, but the domain may not be accessible normally. At this point, you either wait idly or find ways to complete the work without violating regulations.
This article focuses only on technically actionable debugging methods and troubleshooting思路. Specific requirements depend on local communications administration departments and service providers’ regulations.
First, Distinguish the Cause of “Inaccessibility”
A domain being inaccessible doesn’t necessarily mean it’s a filing issue. Make this distinction first; otherwise, you’ll waste time in the wrong direction.
| Phenomenon | Possible Cause | Quick Judgment Criteria |
|---|---|---|
| Browser shows blocked message with filing-related prompts | Not filed / Filing not approved | The prompt page itself explains the reason |
| Connection timeout | Safety group/firewall not allowing traffic, service not started | Test with nc -zv IP 80 |
| Connection refused | No service listening on port | Check listeners with ss -lntp |
| Connected but returns error page | Web service configuration issue | Check status code with curl -I |
| Accessible in some regions, not others | DNS propagation delay / Carrier policies | Compare results using dig from multiple locations |
# ① Which server does the domain resolve to?
dig +short example.com A
# ② Is the port reachable? (Distinguish between timeout and refusal)
nc -zv ServerIP 80
nc -zv ServerIP 443
# ③ Test the server directly by bypassing the domain (to determine if it's a domain-level issue)
curl -I -H 'Host: example.com' http://ServerIP/
# ④ Compare DNS resolution synchronization
dig @8.8.8.8 example.com +short
dig @114.114.114.114 example.com +shortPoint ③ is the key criterion: If you can access the site normally using the IP + specified Host header, the server and site configuration are fine; the problem lies at the domain level (filing, DNS resolution, or blocking). This immediately eliminates half of the possibilities.
Debugging Methods During ICP Filing
Method 1: Modify Local Hosts File (Most Common)
Map the domain to the server IP on your own computer. This only affects your local machine and does not impact any online users.
# Windows: C:WindowsSystem32driversetchosts
# Linux / macOS: /etc/hosts
ServerIP example.com
ServerIP www.example.com# Refresh local DNS cache after modification
ipconfig /flushdns # Windows
sudo systemd-resolve --flush-caches # Linux
sudo dscacheutil -flushcache # macOS
# Confirm effectiveness (check if the resolved IP is the target server)
ping example.com
dig example.com +shortThis is the most practical method for the development and debugging phase: team members configure their own hosts files, allowing them to use domain names for development and testing as usual, without waiting for the filing to be completed.
Method 2: Use Non-Standard Ports for Temporary Debugging
server {
listen 8080; # Temporary port, for internal debugging only
server_name example.com;
root /var/www/html;
}# Allow only your own IP in the security group
# Access via: http://ServerIP:8080/
curl -I http://ServerIP:8080/Note two points: Open only during debugging and close afterwards; and restrict the source IP in the security group. Do not open it to the entire internet.
Method 3: Use Temporary Domains or Direct IP Connection for Verification
If you only need to verify functionality rather than full business operations, you can connect directly via IP, using the Host header:
curl -I -H 'Host: example.com' http://ServerIP/Special Considerations for Migration Scenarios
When migrating a domain that already has an ICP filing to a new server, you usually need to apply for “ICP Filing Access” (Bei’an JieRu) with the new provider. If the operation order is incorrect during this process, temporary inaccessibility may occur.
- Confirm the new server provider’s qualification for filing access — not all providers support this.
- Submit the access application before switching DNS resolution — reversing the order often causes issues.
- Keep the old environment available until the access process is complete.
Decision Tree
Domain inaccessible
├─ curl -I -H 'Host: Domain' http://ServerIP/
│ ├─ Returns normally → Server and site are fine; issue is at the domain level
│ │ ├─ Has filing-related prompt page → Filing incomplete / Not accessed
│ │ ├─ Resolved IP is incorrect → Fix DNS or wait for propagation
│ │ └─ Inconsistent resolution across regions → Wait for TTL or check carrier policies
│ └─ Returns abnormally → Issue is with the server
│ ├─ Timeout → Security group / Firewall
│ ├─ Refused → Service not listening
│ └─ Error page → Web configuration issue
└─ Need to continue development during filing
└─ Modify local hosts file (does not affect online users)Scenario Walkthrough: Domain Just Transferred, Site Suddenly Inaccessible
Phenomenon: A domain has just completed transfer and DNS configuration is starting.
Some regions report it cannot be accessed. It is unclear whether this is a configuration issue or related to the process status.
- First, determine what kind of “inaccessibility” it is → Collect specific phenomena: some regions timeout,
while others work normally; there is no unified error page. This inconsistency points to network path or policy levels, not the site itself. - Rule out self-configuration issues → Check if domain resolution results are normal, if the host is reachable,
and if services are running. If these are all normal, you can confirm it is not a configuration error on your end. - Identify compliance boundaries in this situation → Confirm that this inaccessibility is a normal state during the incomplete process,
not a failure — this determines what actions to take next. - Switch to development and debugging methods that do not rely on public DNS resolution → Map the domain to the server on your local machine.
This allows the webmaster to continue working, although external users temporarily cannot access it. - Alternative debugging method: Directly specify the target server for access → Bypass DNS resolution by using the Host header
to verify if the service responds correctly on that host, leaving no trace on the local machine. - Verify again after the process ends → Once the status is normal, re-confirm accessibility from multiple network environments.
# Confirm if resolution is normal
dig +short example.com A
dig +short example.com NS
# Directly test the target server by specifying its ID/host (bypasses resolution, suitable for debugging)
curl -sS -o /dev/null -w '%{http_code}n' -H 'Host: example.com' http://ServerIP/
# Local debugging: Map domain to server (remember to revert after use)
# Windows: C:WindowsSystem32driversetchosts
# ServerIP example.com www.example.com
# Flush local cache after modification to verify
ipconfig /flushdnsRoot Cause: The compliance process has not yet been completed. Inaccessibility during this period is an expected state,
not a configuration error. The real trouble comes from treating it as a fault and checking the server, wasting time.
Two Key Points to Remember:
- When encountering inaccessibility, first judge whether it is your problem or due to compliance status.
The criterion is “checking if self-inspection items (resolution, host, service) are normal”: if they are all normal but still inaccessible,
it is basically certain to be related to the process status. - The two debugging methods have different uses:
Modifying the local hosts file is suitable for long-term debugging; using the Host header to request the target server directly
is suitable for one-time verification without leaving changes on the local machine.
Comparison of Three Debugging Methods
| Method | Action | What Can Be Verified | Limits |
|---|---|---|---|
| Modify local hosts | Map domain to server IP | Programs, databases, pseudo-static rules | Only affects the modified computer |
| Direct IP connection | Access via IP + Port | Whether the Web service itself is functioning | Cannot locate specific sites under virtual hosting |
| Temporary access address | Use temporary domain provided by the service provider | Access paths close to reality | Requires provider support, domain may change |
| Switch to non-standard port | Temporarily listen on other ports for debugging | Program logic and configuration | Must remember to close after debugging |
Among these four methods, modifying hosts is the most commonly used and most easily misjudged one.
It verifies “whether the server and program have issues,” but bypasses the DNS resolution step;
so if it opens under hosts, it only proves the server side is normal, it does not prove that the site is accessible externally during the filing period.
# Local hosts verification (Windows: C:WindowsSystem32driversetchosts)
# 1.2.3.4 example.com www.example.com
# Immediately verify after modification if resolution points to the target IP
nslookup example.com
# or
ping -c 1 example.com
# Clear local DNS cache to avoid interference from old results
ipconfig /flushdns # Windows
systemd-resolve --flush-caches # Linux (systemd-resolved)
# Specify server IP to fetch response directly (does not rely on resolution)
curl -sS -o /dev/null -w '%{http_code}n' -H 'Host: example.com' http://1.2.3.4/The last curl command with the Host header is worth remembering:
it can verify whether the response from the corresponding site on the target server is normal without modifying hosts or DNS resolution.
It can be operated on a machine unrelated to production, leaving no trace after debugging.
8 Common Pitfalls
- Acting without distinguishing causes: Verify once with IP + Host header to immediately distinguish between server issues and domain issues.
- Waiting idly during filing: You can continue development by modifying local hosts; no need to stop.
- Forgetting to apply for filing access when changing providers: Server migration and filing access are two separate things.
- Shutting down the old environment before access is complete: No fallback, leading to direct business interruption.
- Leaving debugging ports open long-term: Close temporary ports after use, and must restrict source IPs.
- Forgetting to refresh cache after modifying hosts: If you don’t flushdns after modification, you still see the old resolution.
- Inconsistent hosts configurations in multi-person collaboration: Configurations must be consistent among team members, otherwise false judgments like “it works for him” will occur.
- Treating blocking prompts as website faults to fix: The prompt page already explains the reason; no need to check the server.
Real Customer Feedback (From Similar Product Reviews and Consultations on Cloud Markets)
The following excerpts are from real buyer reviews and consultations for similar IT operations services on Alibaba Cloud / Tencent Cloud / Huawei Cloud cloud markets (service providers include our store and peers, for reference only, not fictional tickets from this site):
a****8 Rating: 5.0 2023-08-11 15:44
h****7 Rating: 5.0 2023-10-30 16:18 h****8 Rating: 5.0 2023-10-07 18:10 Chen****wu Rating: 5.0 2023-07-31 16:28 Long****sheng Rating: 5.0 2022-08-28 12:30
10***02 2024-07-30 5.0 Safe and reliable | Affordable price | Skilled technology Fast handling, good configuration 10***18 2024-07-22 5.0 On-time delivery | Affordable price | Complete after-sales Expert in handling filing issues 10***58 2024-03-06 5.0 Skilled technology | Patient and professional Timely and efficient, handling filing issues 10***77 2022-09-28 5.0 Safe and reliable | On-time delivery | Skilled technology Received filing rectification notice, purchased this service, handled quickly. 10***71 2022-09-26 5.0 Affordable price | Skilled technology | Timely reply (User did not fill in comment content) 10***92 2022-09-22 5.0 On-time delivery | Patient and professional | Skilled technology (User did not fill in comment content) 10***13 2022-09-03 5.0 Affordable price | Skilled technology | Timely reply Used for filing rectification 10***42 2022-08-16 5.0 Affordable price | Skilled technology | Complete after-sales The technician is skilled and good 10***75 2022-07-25 5.0 Comprehensive functions | Affordable price | Patient and professional Filing rectification, needed service 10***25 2022-07-04 5.0 Comprehensive functions | Affordable price | Skilled technology (User did not fill in comment content)