跳到主要内容
MyIPKit— 读懂你的网络。

How to report a network problem so it gets fixed

What to put in a message to IT support or your provider so the first reply is a fix rather than a question — with a template to copy.

Updated 2026年9月25日3 min read

Information:

Shown in English

This guide has not been translated into your language yet, so you are reading the English original. The rest of the site stays in the language you chose.
Warning:

Before you run anything

These guides are reference material, not instructions for your particular network. Run commands only against networks you own or have explicit permission to examine — in many countries probing a network you are not authorised to touch is a criminal offence regardless of intent. Everything here is provided without warranty: you are responsible for what you run and for its effect on your systems.

Most support tickets about networks go back and forth three times before anyone looks at the actual problem: when did it start, is it just you, what have you tried. Answer those in the first message and the first reply can be a fix.

Before you write anything

Work out the scope. It changes who should receive the report as much as what goes in it.

  • One site, or everything? If one site is slow or down and others are fine, the problem is that site. Report it to them, not your provider.
  • One device, or all of them? If your phone works and your laptop does not, the network is probably fine and the laptop is not.
  • Wi-fi, or cable too? If a cable fixes it, it is a wireless problem inside your building.

A checking order for a bad connection walks through this properly. Five minutes there often means the report goes to the right people first time.

What to include

  1. What you expected, and what happened instead. “Pages time out” is less useful than “github.com shows ERR_CONNECTION_TIMED_OUT after about 30 seconds; other sites load normally.” Quote error messages exactly, or attach a screenshot.
  2. When it started, and whether it is constant. An exact time lets someone find the matching entry in their logs. “Every evening from about 8pm” points at congestion; “since Tuesday’s maintenance window” points at a change.
  3. What else is affected. Other devices, other people in the building, other networks — does it work on mobile data?
  4. Your public IP address and provider. They may need it to find your connection in their systems. The network report collects it, along with your browser, connection type and latency, and can mask the address if you are posting somewhere public.
  5. Evidence. Two or three short command outputs are worth more than a paragraph of description:
    • a ping to your router and to 1.1.1.1, which separates a local fault from a wider one;
    • a DNS lookup of the failing name, which separates a name problem from a connection problem;
    • a traceroute or mtr to the failing destination and to one that works, run two or three times. A single trace proves very little — see reading traceroute for why.
  6. What you have already tried. Restarted the router, tried another DNS server, used a cable. This saves them asking you to do it again.

A template

Problem:    <what fails, with the exact error message>
Expected:   <what should have happened>
Since:      <date and time it started>  Constant / intermittent: <which>
Affects:    <this device only / all devices / everyone on this network>
            <works on mobile data: yes / no>
Network:    <provider>, public IP <address or "attached report">
Tried:      <router restart, other DNS, cable, other browser...>

Evidence:
  ping <router>      -> <loss %, typical time>
  ping 1.1.1.1       -> <loss %, typical time>
  DNS lookup <name>  -> <answer or error>
  traceroute to failing destination (x3) and to a working one: attached

Before posting in public

If you are asking in a forum rather than a private ticket, remove anything that identifies your network or grants access to it:

  • your public IP address (the network report can mask it for you),
  • internal hostnames and addresses that reveal how your network is laid out,
  • anything resembling a password, token or API key — these turn up in pasted logs more often than people expect.

Who to send it to

  • A single website or service misbehaving — that site’s support or status page.
  • Your connection at home — your internet provider.
  • Your connection at work — your IT team, who can see logs you cannot.
  • Email bouncing or landing in spam — the provider that sends the mail, and check its DNS records first with the SPF, DKIM and DMARC check.

All guides